View SN260_1264440.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

december 2007 rev 2 1/88 1 SN260 zigbee? 802.15.4 network processor features integrated 2.4ghz, i eee 802.15.4-compliant transceiver: ? robust rx filtering allows co-existence with ieee 802.11g an d bluetooth devices ? - 97.5dbm rx sensitivity (1% per, 20byte packet) ? + 3dbm nominal output power ? increased radio performance mode (boost mode) gives ?98.5dbm sensitivity and +5dbm transmit power ? integrated vco and loop filter ? secondary tx-only rf port for applications requiring external pa. integrated ieee 802 .15.4 phy and mac dedicated peripherals and integrated memory emberznet? zigbee?-compliant stack running on the dedicated network processor controlled by the host using the emberznet? serial protocol (ezsp) ? standard serial interface (allows for connection to a variety of host micro controllers) non-intrusive debug interface (sif) integrated hardware and software support for insight development environment provides integrated rc oscillator for low power operation three sleep modes: ? processor idle (automatic) ? deep sleep?1.0a ? power down?1.0a watchdog timer and power-on-reset circuitry integrated aes encryption accelerator integrated 1.8v voltage regulator compatible wit h ember em250 always powered packettrace adc rf_p,n integrated flash and ram sif_miso hf osc sif internal rc-osc io controller chip manager regulator bias interrupt controller rf_tx_alt_p,n osca oscb sif_mosi sif_clk nsif_load encryption acclerator if network processor (xap2b) vreg_out watchdog pa select lna pa pa dac mac + baseband tx_active sleep timer bias_r por network processor peripherals serial controller synth sclk miso mosi nssel link_activity nhost_int nwake nreset nssel_int pti_en pti_data sdbg www.st.com
contents SN260 2/88 contents 1 general description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 pin assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 top-level functional descrip tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 electrical characteristi cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 absolute maximum ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 recommended operating conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3 environmental characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4 dc electrical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5 digital i/o specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6 rf electrical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6.1 receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6.2 transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6.3 synthesizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5 functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1 receive (rx) path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1 rx baseband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.2 rssi and cca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2 transmit (tx) path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.1 tx baseband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.2 tx_active signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3 integrated mac module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.4 packet trace interface (pti) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.5 16-bit microprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.6 embedded memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.6.1 simulated eeprom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.6.2 flash information area (fia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.7 encryption accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.8 reset detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.9 power-on-reset (por) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
SN260 contents 3/88 5.10 clock sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.10.1 high-frequency crystal oscillator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.10.2 internal rc oscillator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.11 random number generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.12 watchdog timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.13 sleep timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.14 power management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6 spi protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.1 physical interface configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2 spi transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2.1 command section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.2.2 wait section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.2.3 response section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.2.4 asynchronous signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.2.5 spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2.6 waking the SN260 from sleep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2.7 error conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.3 spi protocol timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.4 data format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.5 spi byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.5.1 primary spi bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.5.2 special response bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.6 powering on, power cycling, and rebooting . . . . . . . . . . . . . . . . . . . . . . . 29 6.6.1 unexpected resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.7 transaction examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.7.1 spi protocol version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.7.2 emberznet serial protocol frame ? nop command . . . . . . . . . . . . . . . 30 6.7.3 SN260 reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.7.4 three-part transaction: wake, get version, stack status callback . . . . 32 7 emberznet serial protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1 byte order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.2 conceptual overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.2.1 stack configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.2.2 policy settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
contents SN260 4/88 7.2.3 datagram replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.2.4 callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.2.5 power management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.2.6 tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.2.7 ram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.2.8 SN260 status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.2.9 random number generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.3 protocol format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.3.1 type definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.3.2 structure definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7.3.3 named values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.3.4 configuration frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7.3.5 utilities frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.3.6 networking frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.3.7 binding frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.3.8 messaging frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.3.9 alphabetical list of frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.4 sample transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.4.1 joining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.4.2 binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.4.3 sending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.4.4 receiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 8 sif module programming and debug interface . . . . . . . . . . . . . . . . . . 81 9 typical application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 10 mechanical details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 11 ordering information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 12 abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 13 references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 14 revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
SN260 general description 5/88 1 general description the SN260 integrates a 2.4ghz , ieee 802.15.4-complia nt transceiver with a 16-bit network processor (xap2 b core) to run emberznet, the zigb ee-compliant network stack. the SN260 exposes access to the emberznet api across a standard spi module, allowing application development on a host processor. this means that the SN260 can be viewed as a zigbee peripheral connected over a spi. th e xap2b microprocessor is a power-optimized core integrated in the SN260. it contains integrated flash and ram memory along with an optimized peripheral set to enhance the operation of the network stack. the transceiver utilizes an efficient arch itecture that exceeds the dynamic range requirements imposed by the ieee 802.15.4-2003 standard by over 15db. the integrated receive channel filtering allows for co-existence with other communication standards in the 2.4ghz spectrum such as ieee 802.11g and bluetooth. the integrated regulator, vco, loop filter, and power amplifier keep the external component count low. an optional high- performance radio mode (boost mode) is software selectable to boost dynamic range by a further 3db. the SN260 contains embedded flash and integrated ram for program and data storage. by employing an effective wear-leveling algorithm, the stack optimizes the lifetime of the embedded flash, and affords th e application the ability to co nfigure stack a nd application tokens within the SN260. to maintain the strict timi ng requirements imposed by zi gbee and the i eee 802.15.4-2003 standard, the SN260 integrates a number of mac functions into the hardware. the mac hardware handles automatic ack transmission and reception, automatic backoff delay, and clear channel assessment for transmission, as well as automatic filtering of received packets. in addition, the SN260 allows for true mac level debugging by integrating the packet trace interface. an integrated voltage regulator, power-on-reset circuitry, sleep timer, and low-power sleep modes are available. the deep sleep and power down modes draws less than 1 a, allowing products to achieve long battery life. finally, the SN260 utilizes the non-intrusive sif module for powerful software debugging and programming of the network processor. target applications for the SN260 include: building automation and control home automation and control home entertainment control asset tracking the SN260 can only be purchased with the embe rznet stack. this technical datasheet details the SN260 features available to customers using it with the emberznet stack.
pin assignment SN260 6/88 2 pin assignment figure 1. SN260 pin assignment vdd_vco rf_p vdd_rf rf_n rf_tx_alt_p rf_tx_alt_n vdd_if bias_r vdd_padsa tx_active nsif_load sif_mosi sif_miso sif_clk nhost_in t res vdd_pads pti_data pti_en nssel gnd vdd_flash sdbg link_activity nwake vdd_core vdd_synth_pre oscb osca vdd_24mhz sclk miso mosi nssel_int v dd_core vdd_pads nreset vdd_pads vreg_out res 11 12 13 14 15 16 17 18 19 20 10 9 8 7 6 5 4 3 2 1 21 22 23 24 25 26 27 28 29 30 40 39 38 37 36 35 34 33 32 31 41 gnd em260 SN260 table 1. pin descriptions pin # signal direction description 1 vdd_vco power 1.8v vco supply 2 rf_p i/o differential (with rf_n) receiver input/transmitter output 3 rf_n i/o differential (with rf_p) receiver input/transmitter output 4 vdd_rf power 1.8v rf supply (lna and pa) 5 rf_tx_alt_p o differential (with rf_tx_ alt_n) transmitter output (optional) 6 rf_tx_alt_n o differential (with rf_tx_ alt_p) transmitter output (optional) 7 vdd_if power 1.8v if supply (mixers and filters) 8 bias_r i bias setting resistor 9 vdd_padsa power analog pad supply (1.8v) 10 tx_active o logic-level control for external rx/tx switch the SN260 baseband controls tx_active and drives it high (1.8v) when in tx mode. (refer to ta bl e 6 and section tx_active signal.)
SN260 pin assignment 7/88 11 nreset i active low chip reset (internal pull-up) 12 vreg_out power regulator output (1.8v) 13 vdd_pads power pads supply (2.1 ? 3.6v) 14 vdd_core power 1.8v digital core supply 15 nssel_int i spi slave select interrup t (from host to SN260) this signal must be con nected to nssel (pin 21) 16 res reserved for future use, do not connect to any signal. 17 mosi i spi data, master out / slave in (from host to SN260) 18 miso o spi data, master in / slave out (from SN260 to host) 19 vdd_pads power pads supply (2.1 ? 3.6v) 20 sclk i spi clock (from host to SN260) 21 nssel i spi slave select (from host to SN260) 22 pti_en o frame signal of packet trace interface (pti) 23 pti_data o data signal of packet trace interface (pti) 24 vdd_pads power pads supply (2.1 ? 3.6v) 25 res reserved for future use, do not connect to any signal. 26 nhost_int o host interrupt signal (from SN260 to host) 27 sif_clk i serial interface, clock (internal pull down) 28 sif_miso o serial interface, master in / slave out 29 sif_mosi i serial interface, master out / slave in 30 nsif_load i/o serial interface, load strobe (open collector with internal pull up) 31 gnd power ground supply 32 vdd_flash power 1.8v flash memory supply 33 sdbg o spare debug signal 34 link_activity o link and activity signal 35 nwake i wake interrupt signal (from host to SN260) 36 vdd_core power 1.8v digital core supply 37 vdd_synth_pre power 1.8v synthesizer and pre-scalar supply 38 oscb i/o 24mhz crystal oscillator or left open for when using an external clock input on osca 39 osca i/o 24mhz crystal oscillator or external clock input 40 vdd_24mhz power 1.8v high-frequency oscillator supply 41 gnd ground ground supply pad in the bottom center of the package forms pin 41 (see the em260 reference design for pcb considerations) table 1. pin descriptions (continued) pin # signal direction description
top-level functional description SN260 8/88 3 top-level functional description figure 2 shows a detailed block diagram of the SN260. figure 2. SN260 block diagram the radio receiver is a low-if, super-heterodyne receiver. it utilizes differential signal paths to minimize noise interference, and its architecture has been chosen to optimize co- existence with other devices within the 2.4ghz band (namely, ieee 802.11g an d bluetooth). after amplification and mixing, the signal is filtered and combined prior to being sampled by an adc. the digital receiver implements a coherent demodulator to generate a chip stream for the hardware-based mac. in addition, the digital receiver contains the analog radio calibration routines and control of the gain within the receiver path. the radio transmitter utilizes an efficient archit ecture in which the da ta stream directly modulates the vco. an integrated pa boosts the output power. the calibration of the tx path as well as the output power is controlled by digital logic. if the SN260 is to be used with an external pa, the tx_active signal should be used to control the timing of the external switching logic. the integrated 4.8ghz vco and loop filter minimize off-chip circuitry. only a 24mhz crystal with its loading capacitors is required to properly establish the pll reference signal. the mac interfaces the data memory to the rx and tx baseband modules. the mac provides hardware-based ieee 802.15.4 packet-level filtering. it supplies an accurate symbol time base that minimizes the synchronization effort of the software stack and meets the protocol timing requirements. in addition, it provides timer and synchronization assistance for th e ieee 802.15.4 csma-ca algorithm. always powered packettrace adc rf_p,n integrated flash and ram sif_miso hf osc sif internal rc-osc io controller chip manager regulator bias interrupt controller rf_tx_alt_p,n osca oscb sif_mosi sif_clk nsif_load encryption acclerator if network processor (xap2b) vreg_out watchdog pa select lna pa pa dac mac + baseband tx_active sleep timer bias_r por network processor peripherals serial controller synth sclk miso mosi nssel link_activity nhost_int nwake nreset nssel_int pti_en pti_data sdbg
SN260 top-level functional description 9/88 the SN260 integrates hardware support for a packet trace module, which allows robust packet-based debug. this element is a critical component of insight desktop, the ember software ide, providing advanced network de bug capability when coup led with the insight adapter. the SN260 integrates a 16-bit xap2b microprocessor developed by cambridge consultants ltd. this power-efficient, industry-proven core provides the appropriate level of processing power to meet the needs of the emberznet zigbee-compliant stack, emberznet. in addition, the sif module provides a non-intrusive programming and debug interface allowing for real-time application debugging. the SN260 exposes the emberznet serial api over the spi, which allows application development to occur on a host micro controller of choice. in addition to the four spi signals, two additional signals, nhost_int and nwake, provide an easy-to-use handshake mechanism between the host and the SN260. the integrated voltage regulator generates a regulated 1.8v reference voltage from an unregulated supply voltage. this voltage is decoupled and routed externally to supply the 1.8v to the core logic. in addition, an integrated por module allows for the proper cold start of the SN260. the SN260 contains one high -frequency (24mhz) crystal o scillator and, for low-power operation, a second low-frequency internal 10 khz oscillator. the SN260 contains two power domains. the always-powered high voltage supply is used for powering the gpio pads and critical chip fu nctions. the rest of the chip is powered by a regulated low voltage supply which can be disabled during deep sleep to reduce the power consumption.
electrical characteristics SN260 10/88 4 electrical characteristics 4.1 absolute maximum ratings ta bl e 2 lists the absolute maximum ratings for the SN260. 4.2 recommended operating conditions ta bl e 3 lists the rated operating conditions of the SN260. table 2. absolute maximum ratings parameter test conditions min. max. unit regulator voltage (vdd_pads) - 0.3 3.6 v core voltage (vdd_24mhz, vdd_vco, vdd_rf, vdd_if, vdd_padsa, vdd_flash, vdd_synth_pre, vdd_core) - 0.3 2.0 v voltage on rf_p,n; rf_tx_alt_p,n - 0.3 3.6 v voltage on nssel_int, mosi, miso, sclk, nssel, pti_en, pti_data, nhost_int, sif_clk, sif_miso, si f_mosi, nsif_load, sdbg, link_activity, nwake, nreset, vreg_out - 0.3 vdd_pads+0.3 v voltage on tx_active, bias_r, osca, oscb - 0.3 vdd_core+0.3 v storage temperature - 40 + 140 c table 3. operating conditions parameter test conditions min. typ. max. unit regulator input voltage (vdd_pads) 2.1 3.6 v core input voltage (vdd_24mhz, vdd_vco, vdd_rf, vdd_if, vdd_padsa, vdd_flash, vdd_synth_pre, vdd_core) 1.7 1.8 1.9 v temperature range - 40 + 85 c
SN260 electrical characteristics 11/88 4.3 environmental characteristics ta bl e 4 lists the environmental characteristics of the SN260. 4.4 dc electrical characteristics ta bl e 5 lists the dc electrical c haracteristics of the SN260. table 4. environmental characteristics parameter test conditions min. typ. max. unit esd (human body model) on any pin - 2 + 2 kv esd (charged device model) non-rf pins - 400 + 400 v esd (charged device model) rf pins - 225 + 225 v msl (moisture sensitivity level) tbd table 5. dc characteristics parameter test conditions min. typ. max. unit regulator input voltage (vdd_pads) 2.1 3.6 v power supply range (vdd_core) regulator output or external input 1.7 1.8 1.9 v deep sleep current quiescent current, including internal rc oscillator at 25 c 1.0 a rx current radio receiver, mac, and baseband (boost mode) 29.0 ma radio receiver, mac, and baseband 27.0 ma cpu, ram, and flash memory at 25 c and 1.8v core 8.5 ma total rx current ( = i radio receiver, mac and baseband, cpu + i ram, and flash memory ) at 25 c, vdd_pads = 3.0v 35.5 ma tx current radio transmitter, mac, and baseband (boost mode) at max. tx power (+ 5dbm typical) 33.0 ma radio transmitter, mac, and baseband at max. tx power (+ 3dbm typical) 27.0 ma at 0dbm typical 24.3 ma at min. tx power (- 32dbm typical) 19.5 ma cpu, ram, and flash memory at 25 c, vdd_pads = 3.0v 8.5 ma total tx current ( = i radio transmitter, mac and baseband, cpu + i ram, and flash memory ) at 25 c and 1.8v core; max. power out 35.5 ma
electrical characteristics SN260 12/88 4.5 digital i/o specifications ta bl e 6 contains the digital i/o specifications for the SN260. the digital i/o power (named vdd_pads) comes from three dedicated pins (pins 13, 19, and 24). the voltage applied to these pins sets the i/o voltage. table 6. digital i/o specifications parameter name min. typ. max. unit voltage supply vdd_pads 2.1 3.6 v input voltage for logic 0 v il 0 0.2 x vdd_pads v input voltage for logic 1 v ih 0.8 x vdd_pads vdd_pads v input current for logic 0 i il -0.5 a input current for logic 1 i ih 0.5 a input pull-up resistor value r ipu 30 k input pull-down resistor value r ipd 30 k output voltage for logic 0 v ol 0 0.18 x vdd_pads v output voltage for logic 1 v oh 0.82 x vdd_pads vdd_pads v output source current (standard current pad) i ohs 4ma output sink current (standard current pad) i ols 4ma output source current (high current pad: pins 33, 34, and 35) i ohh 8ma output sink current (high current pad: pins 33, 34, and 35) i olh 8ma total output current (for i/o pads) i oh + i ol 40 ma input voltage threshold for osca 0.2 x vdd_core 0.8 x vdd_pads v output voltage level (tx_active) 0. 18 x vdd_core 0.82 x vdd_core v output source current (tx_active) 1 ma
SN260 electrical characteristics 13/88 4.6 rf electrical characteristics 4.6.1 receive ta bl e 7 lists the key parameters of the integrated ieee 802.15.4 receiver on the SN260. note: receive measurements were collected with ember?s em260 reference design at 2440mhz. the typical number indicates one standard deviation above the mean. table 7. receive characteristics parameter test conditions min. typ. max. unit frequency range 2400 2500 mhz sensitivity (boost mode) 1% per, 20byte packet defined by ieee 802.15.4 - 93 - 98.5 dbm sensitivity 1% per, 20byte packet defined by ieee 802.15.4 - 92 - 97.5 dbm high-side adjacent channel rejection ieee 802.15.4 signal at -82dbm 35 db low-side adjacent channel rejection ieee 802.15.4 signal at - 82dbm 35 db 2 nd high-side adjacent channel rejection ieee 802.15.4 signal at - 82dbm 40 db 2 nd low-side adjacent channel rejection ieee 802.15.4 signal at - 82dbm 40 db channel rejection for all other channels ieee 802.15.4 signal at - 82dbm 40 db 802.11g rejection centered at + 12mhz or - 13mhz ieee 802.15.4 signal at - 82dbm 40 db maximum input signal level for correct operation (low gain) 0dbm image suppression 30 db co-channel rejection ieee 802.15.4 signal at - 82dbm - 6 dbc relative frequency error (2 x 40 ppm require d by ieee 802.15.4) - 120 + 120 ppm relative timing error (2 x 40 ppm require d by ieee 802.15.4) - 120 + 120 ppm linear rssi range 40 db
electrical characteristics SN260 14/88 4.6.2 transmit ta bl e 8 lists the key parameters of the integrated ieee 802.15.4 transmitter on the SN260. note: transmit measurements were collected with ember?s em260 reference design at 2440mhz. the typical number indicates one standard deviation below the mean. 4.6.3 synthesizer ta bl e 9 lists the key parameters of the integrated synthesizer on the SN260. table 8. transmit characteristics parameter test conditions min. typ. max. unit maximum output power (boost mode) at highest power setting 5 dbm maximum output power at highest power setting 0 3 dbm minimum output power at lowest power setting - 32 dbm error vector magnitude as defined by ieee 802.15.4, which sets a 35% maximum 15 25 % carrier frequency error - 40 + 40 ppm load impedance 200 psd mask relative 3.5mhz away - 20 db psd mask absolute 3.5mhz away - 30 dbm table 9. synthesizer characteristics parameter test conditions min. typ. max. unit frequency range 2400 2500 mhz frequency resolution 11.7 khz lock time from off, with correct vco dac setting 100 s relock time channel change or rx/tx turnaround (ieee 802.15.4 defines 192s turnaround time) 100 s phase noise at 100khz - 71 dbc/hz phase noise at 1mhz - 91 dbc/hz phase noise at 4mhz - 103 dbc/hz phase noise at 10mhz - 111 dbc/hz
SN260 functional description 15/88 5 functional description the SN260 connects to the host micro controller through a standard spi interface. the emberznet serial protocol (ezsp) has been defined to allow an application to be written on a host micro controller of choice. therefore, the SN260 comes with a license to emberznet, the emberznet zigbee-compliant software stack. the following brief description of the hardware modules provides the necessary background on the operation of the SN260. for more information, contact your local st sales representative. 5.1 receive (rx) path the SN260 rx path spans the analog and digita l domains. the rx architecture is based on a low-if, super-heterodyne receiver. it utilizes differential signal paths to minimize noise interference. the input rf signal is mixed down to the if frequency of 4mhz by i and q mixers. the output of the mixers is filtered and combined prior to being sampled by a 12msps adc. the rx filtering within the rx path has been designed to optimize the co- existence of the SN260 with other 2.4ghz transceivers, such as the ieee 802.11g and bluetooth. 5.1.1 rx baseband the SN260 rx baseband (within the digital domain) implements a coherent demodulator for optimal performance. the base band demodulates th e o-qpsk signal at the chip level and synchronizes with the ieee 802.15.4-2003 preamble. once a packet preamble is detected, it de-spreads the demodulated data into 4-bit symbols. these symbols are buffered and passed to the hardware-based mac module for filtering. in addition, the rx baseband provides the calibration and control interface to the analog rx modules, including the lna, rx baseband fi lter, and modulation modules. the emberznet software includes calibration algorithms which use this interface to reduce the effects of process and temperature variation. 5.1.2 rssi and cca the SN260 calculates the rssi over an 8-symbol period as well as at the end of a received packet. it utilizes the rx gain settings and th e output level of the a dc within its algorithm. the SN260 rx baseban d provides support for the i eee 802.15.4-2003 required cca methods summarized in ta bl e 1 0 . modes 1, 2, and 3 are defined by the 802.15.4-2003 standard; mode 0 is a proprietary mode. table 10. cca mode behavior cca mode mode behavior 0 clear channel reports busy medium if either carrier sense or rssi exceeds their thresholds. 1 clear channel reports busy medium if rssi exceeds its threshold. 2 clear channel reports busy medium if carrier sense exceeds its threshold. 3 clear channel reports busy medium if bot h rssi and carrier sense exceed their thresholds.
functional description SN260 16/88 5.2 transmit (tx) path the SN260 transmitter utilizes bot h analog circuitry and digita l logic to produce the o-qpsk modulated signal. the area-efficient tx architecture directly modulates the spread symbols prior to transmission. the differential signal paths increase noise immunity and provide a common interface for the external balun. 5.2.1 tx baseband the SN260 tx baseband (within the digital domain) performs the spreading of the 4-bit symbol into its ieee 802.15.4- 2003-defined 32-chip i and q sequence. in addition, it provides the interface for software to perform the calibration of the tx module in order to reduce process, temperature, and voltage variations. 5.2.2 tx_active signal even though the SN260 provides an output power suitable for most zigbee applications, some applications will require an external po wer amplifier (pa). due to the timing requirements of ieee 802.15.4-20 03, the sn250 provides a signa l, tx_active, to be used for external pa power management and rf switching logic. when in tx, the tx baseband drives tx_active high (as described in ta b l e 6 ). when in rx, the tx_active signal is low. if an external pa is not required, then the tx_active signal should be connected to gnd through a 100k ohm resistor, as shown in the application circuit in figure 12 . 5.3 integrated mac module the SN260 integrates critical portions of the ieee 802.15. 4-2003 mac requirements in hardware. this allows the SN260 to provide greater bandwidth to application and network operations. in addition, the hardware acts as a first-line filter for non-intended packets. the SN260 mac utilizes a dma interface to ram me mory to further reduce the overall micro controller interaction when tran smitting or receiving packets. when a packet is ready for transmission, the software configures the tx mac dma by indicating the packet buffer ram location. the mac waits for the backoff period, then transitions the baseband to tx mode and performs channel assessment. when the channel is clear, the mac reads data from the ram buffer, calculates the crc, and provides 4-bit symbols to the baseband. when the final byte has been read and sent to the baseband, the crc remainder is read and transmitted. the mac resides in rx mode most of the time, and different format and address filters keep non-intended packets from using excessive ram buffers, as well as preventing the SN260 cpu from being interrupted. when the reception of a packet begins, the mac reads 4-bit symbols from the baseband and calculates the crc. it assembles the received data for storage in a ram buffer. a rx mac dma provides direct access to the ram memory. once the packet has been received, additional data is appended to the end of the packet in the ram buffer space. the appended data provides statistical information on the packet for the software stack.
SN260 functional description 17/88 the primary features of the mac are: crc generation, appending, and checking hardware timers and interrupts to achieve the mac symbol timing automatic preamble, and sfd pre-pended to a tx packet address recognition and packet filtering on received packets automatic acknowledgement transmission automatic transmission of packets from memory automatic transmission after backoff time if channel is clear (cca) automatic acknowledgement checking time stamping of received and transmitted messages attaching packet information to received packets (lqi, rssi, gain, time stamp, and packet status) ieee 802.15.4-2003 timing and slotted/unslotted timing 5.4 packet trace interface (pti) the SN260 integrates a true phy-level pti for effective network-level debugging. this two- signal interface monitors all the phy tx and rx packets (in a non-intrusive manner) between the mac and baseband modules. it is an asynchronous 500kbps interface and cannot be used to inject packets into the phy/mac interface. the two signals from the SN260 are the frame signal (pti_en) and the data signal (pti_data). the pti is supported by insight desktop. 5.5 16-bit microprocessor the SN260 integrates the xap2b microprocessor developed by cambridge consultants ltd., making it a true network processo r solution. the xap2b is a 16-bit harvard architecture processor with separate program and data address spaces. the word width is 16 bits for both the program and data sides. the standard xap2 microp rocessor and accompanying softw are tools have been enhanced to create the xap2b microprocessor used in the SN260. the xap2b adds data-side byte addressing support to the xap2 allowing for more productive usage of ram and optimized code. the xap2b clock speed is 12mhz. when used with the emberznet stack, firmware is loaded into flash memory over the air or by a serial link using a built-in bootloader in a reserved area of the flash. alternatively, firmware may be loaded via the sif interface with the assistance of ram- based utility routines also loaded via sif. 5.6 embedded memory the SN260 contains embedded flash and ram memory for firmware storage and execution. in addition it pa rtitions a portion of the flas h for simulated eeprom and token storage.
functional description SN260 18/88 5.6.1 simulated eeprom the protocol stack reserves a section of flash memory to provide simulated eeprom storage area for stack and customer tokens. the flash cell has been qualified for a data retention time of >100 years at room temperature and is rated to have a guaranteed 1,000 write/erase cycles. because the flash cells ar e qualified for up to 1,000 write cycles, the simulated eeprom implements an effective wear-leveling algorithm which effectively extends the number of write cycles for individual tokens. the number of set-token operations is finite due to the write cycle limitation of the flash. it is not possible to guarantee an exact number of set-token operations because the life of the simulated eeprom depends on which tokens are written and how often. the SN260 stores non-volatile information necessary for network operation as well as 8 tokens available to the host (see section section 7.2.6: tokens on page 37 ). the majority of internal tokens are only written when the SN260 performs a network join or leave operation. as a simple estimate of possible set-token operations, consider an SN260 in a stable network (no joins or leaves) not sending any messages where the host uses only one of the 8-byte tokens available to it. under this scenario, a very rough estimate results in approximately 330,000 possible set-token operations. the number of possible set-token calls, though, depends on which tokens are being set, so the ratios of set-token calls for each token plays a large factor. a very rough estimate for the total number of times an app token can be set is approximately 320,000. these estimates would typically increase if the SN260 is kept closer to room temperature, since the 1,000 guaranteed write cycles of the flash is for across temperature. 5.6.2 flash information area (fia) the SN260 also includes a separate 1024-byte fia that can be used for storage of data during manufacturing, including serial numbers and calibration values. programming of this special flash page can only be enabled using the sif interface to prevent accidental corruption or erasure. the emberznet stack reserves a small portion of this space for its own use and in addition makes eight manufacturing tokens available to the application. see section 7.2.6: tokens on page 37 , for more information. 5.7 encryption accelerator the SN260 contains a hardware aes encryption engine that is attached to the cpu using a memory-mapped interface. nist-based ccm, ccm*, cbc-mac, and ctr modes are implemented in hardware. these modes are de scribed in the ieee 802.15.4-2003 specification, with the exception of ccm*, which is described in the zigbee security services specification 1.0. the emberznet stack implements a security api for applications that require security at the application level.
SN260 functional description 19/88 5.8 reset detection the SN260 contains multiple reset sources. the reset event is logged into the reset source register, which lets the cpu determine the cause of the last reset. the following reset causes are detected: power-on-reset watchdog pc rollover software reset core power dip 5.9 power-on-reset (por) each voltage domain (1.8v digital core su pply vdd_core and pads supply vdd_pads) has a power-on-reset (por) cell. the vdd_pads por cell holds the always-powered high-voltage domain in reset until the following conditions have been met: the high-voltage pads supply vdd_pads voltage rises above a threshold. the internal rc clock starts and generates three clock pulses. the 1.8v por cell holds the main digital core in reset until the regulator output voltage rises above a threshold. additionally, the digital domain counts 1,024 clock edges on the 24mhz crystal before releasing the reset to the main digital core. ta bl e 1 1 lists the features of the SN260 por circuitry. 5.10 clock sources the SN260 integrates two oscillators: a high-f requency 24mhz crystal oscillator and a low- frequency internal 10khz rc oscillator. 5.10.1 high-frequency crystal oscillator the integrated high-freque ncy crystal oscillator requires an external 24mhz crystal with an accuracy of 40ppm. based upon the applicat ion bill of materials a nd current consumption requirements, the external crystal can cover a range of esr requirements. for a lower esr, the cost of the crystal increases but the over all current consumption decreases. likewise, for higher esr, the cost decreases but the current consumption increases. therefore, the designer can choose a crystal to fit the needs of the application. table 11. por specifications parameter min. typ. max. unit vdd_pads por release 1.0 1.2 1.4 v vdd_pads por assert 0.5 0.6 0.7 v 1.8v por release 1.35 1.5 1.65 v 1.8v por hysteresis 0.08 0.1 0.12 v
functional description SN260 20/88 ta bl e 1 2 lists the specifications for the high-frequency crystal. 5.10.2 internal rc oscillator the SN260 has a low-power, low-frequency rc os cillator that runs all the time. its nominal frequency is 10khz. it is divided down to 1khz using a variable divider to allow software to accurately calibrate it. this calibra ted clock is used by the sleep timer. time-keeping accuracy depends on temperature fluctuations the chip is exposed to, power supply impedance, and the calibration interval, but in general it will be better than 150ppm (including crystal error of 40ppm). ta bl e 1 3 lists the specifications of the rc oscillator. table 12. high-frequency crystal specifications parameter test conditions min. typ. max. unit frequency 24 mhz duty cycle 40 60 % phase noise from 1khz to 100khz - 120 dbc/hz accuracy initial, temperature, and aging - 40 + 40 ppm crystal esr load capacitance of 10pf 100 w crystal esr load capacitance of 18pf 60 w start-up time to stable clock (max. bias) 1ms start-up time to stable clock (optimum bias) 2ms current consumption good crystal: 20 esr, 10pf load 0.2 0.3 ma current consumption worst-case crystals (60 , 18pf or 100 , 10pf) 0.5 ma current consumption at maximum bias 1 ma table 13. rc oscillator specifications parameter test conditions min. typ. max. unit frequency 10 khz analog trim steps 1 khz frequency variation with supply for a voltage drop from 3.6v to 3.1v or 2.6v to 2.1v 0.75 1.5 %
SN260 functional description 21/88 5.11 random number generator the SN260 allows for the generation of random numbers by exposing a randomly generated bit from the rx adc. analog noise current is passed through the rx path, sampled by the receive adc, and stored in a register. the value contained in this register could be used to seed a software-generated ra ndom number. the emberznet stack utilizes these random numbers to seed the random mac backoff and encryption key generators. 5.12 watchdog timer the SN260 contains an internal watchdog timer clocked from the intern al oscillator. if the timer reaches its time-out valu e of approximately 2 seconds, it will reset the SN260. this reset signal cannot be routed externally to the host. the SN260 firmware will periodically restart the watchdog timer while the firmware is running normally. the host cannot effect or configure the watchdog timer. 5.13 sleep timer the 16-bit sleep timer is contained in the always-powered digital block. the clock source for the sleep timer is a calibrated 1khz clock. the frequency is slowed down with a 2 n prescaler to generate a final timer resolution of 1ms. with a 1ms tick and a 16-bit timer, the timer wraps about every 65.5 seconds. the emberznet stack appropriately handles timer wraps allowing the host to orde r a theoretical maximum sle ep delay of 4 million seconds. 5.14 power management the SN260 supports four different power modes: active, idle, deep sleep, and power down. active mode is the normal, operating state of the SN260. while in idle mode, code execution halts until any interrupt occurs. all modules of the SN260 including the radio continue to operate normally. the emberznet stack automatically invokes idle as appropriate. deep sleep mode and power down mode both power off most of the SN260, including the radio, and leave only the critical chip functions powered. the internal regulator is disabled and vreg_out is turned off. all output signals are maintained in a frozen state. upon waking from deep sleep or power down mode, the internal regulator is re-enabled. deep sleep and power down result in the same sleep current consumption. the two sleep modes differ as follows: the SN260 can wake on both an internal timer and an external signal from deep sleep mode; power down mode can only wake on an external signal.
spi protocol SN260 22/88 6 spi protocol the SN260 low level protocol centers on the spi interface for communication with a pair of gpio for handshake signaling. the SN260 looks like a hardware peripheral. the SN260 is the slave device and all transactions are initiated by the host (the master). the SN260 supports a reasonably high data rate. 6.1 physical interface configuration the SN260 supports both spi slave mode 0 (clock is idle low, sample on rising edge) and spi slave mode 3 (clock is idle high, sample on rising edge) at a maximum spi clock rate of 5mhz, as illustrated in figure 3 . note: the convention for the waveforms in this document is to show mode 0. figure 3. spi transfer format, mode 0 and mode 3 the nhost_int signal and the nwake signal are bo th active low. the host must supply a pull-up resistor on the nhost_int signal to prevent errant interruptions during undefined events such as the SN260 resetting. the sn2 60 supplies an internal pull-up on the nwake signal to prevent errant interruptions during undefined events such as the host resetting. 6.2 spi transaction the basic SN260 spi transaction is half-duplex to ensure proper framing and to give the SN260 adequate response time. the basic transaction, as shown in figure 4 , is composed of three sections: command, wait, and response. the transaction can be considered analogous to a function call. the command section is the function call, and the response section is the return value. figure 4. general timing di agram for a spi transaction
SN260 spi protocol 23/88 6.2.1 command section the host begins the transaction by asserting the slave select and then sending a command to the SN260. this command can be of any length from 2 to 128 bytes and must not begin with 0xff . during the command section, the SN260 will respond with only 0xff . the host should ignore data on miso during the command section. once the host has completed transmission of the entire message, the transaction moves to the wait section. 6.2.2 wait section the wait section is a period of time during which the SN260 may be processing the command or performing other operations. note that this section can be any length of time up to 200 milliseconds. because of the variable size of the wait section, an interrupt-driven or polling-driven method is sugges ted for clocking the spi as opposed to a dma method. since the SN260 can require up to 200 millisecon ds to respond, as long as the host keeps slave select active, the host can perform other tasks while waiting for a response. to determine when a response is ready, use one of two methods: clock the spi until the SN260 transmits a byte other than 0xff . interrupt on the falling edge of nhost_int. the first method, clocking the spi, is reco mmended due to simplicity in implementing. during the wait section, the SN260 will transmit only 0xff and will ignore all incoming data until the response is ready. when the SN260 transmits a byte other than 0xff , the transaction has officially moved into the response section. therefore, the host can poll for a response by continuing to clock the spi by transmitting 0xff and waiting for the SN260 to transmit a byte other than 0xff . the SN260 will also indicate that a response is ready by asserting the nhost_int signal. the falling edge of nhost_int is the indication that a response is ready. once the nhost_int si gnal asserts, nhost_int will return to idle after the host begins to clock data. 6.2.3 response section when the SN260 transmits a byte other than 0xff , the transaction has officially moved into the response section. the data format is the same format used in the command section. the response can be of any length from 2 to 12 8 bytes and will not begin with 0xff . depending on the actual response, the length of the response is known from the first or second byte and this length should be used by the host to clock out exactly the correct number of bytes. once all bytes have been clocked, it is allowable for the host to de-assert chip select. since the host is in control of clocking the spi, there are no acks or similar signals needed back from the host because the SN260 will assu me the host could accept the bytes being clocked on the spi. after every transaction, the host must hold the slave select high for a minimum of 1ms. this timing requirement is called the inter-command spacing and is necessary to allow the SN260 to process a command and become ready to accept a new command. 6.2.4 asynchronous signaling when the SN260 has data to send to the host , it will assert the nhost_int signal. the nhost_int signal is designed to be an edge-triggered signal as opposed to a level- triggered signal; therefore, the falling edge of nhost_int is the true indicator of data availability. the host th en has the responsibility to initiate a transaction to ask the SN260 for its output. the host should initiate this transaction as soon as possible to prevent possible
spi protocol SN260 24/88 backup of data in the SN260. the SN260 will de-assert the nhost_int signal after receiving a byte on the spi. due to inherent latency in the SN260, the timing of when the nhost_int signal returns to idle can vary between transactions. nhost_int will always return to idle for a minimum of 10s before asserting again. if the SN260 has more output available after the transaction has completed, the nh ost_int signal will assert again after slave select is de-asserted and the host must make another request. 6.2.5 spacing to ensure that the SN260 is always able to deal with incoming commands, a minimum inter- command spacing is defined at 1ms. after every transaction, the host must hold the slave select high for a minimum of 1ms. the host must respect the inter-command spacing requirement, or the SN260 will not have ti me to operate on th e command; additional commands could result in error conditions or undesired behavior. if the nhost_int signal is not already asserted, the host is allowed to use the wake handshake instead of the inter- command spacing to determine if the SN260 is ready to accept a command. 6.2.6 waking the SN260 from sleep waking up the SN260 involves a simple handshaking routine as illustrated in figure 5 . this handshaking ensures that the host will wait until the SN260 is fully awake and ready to accept commands from the host. if the SN260 is already awake when the handshake is performed (such as when the host resets and the SN260 is already operating), the handshake will proceed as descri bed below with no ill effects. note: a wake handshake cannot be performed if nhost_int is already asserted. figure 5. SN260 wake sequence waking the SN260 involves the following steps: 1. host asserts nwake. 2. SN260 interrupts on nwake and exits sleep. 3. SN260 performs all operations it needs to and will no t respond until it is ready to accept commands. 4. SN260 asserts nhost_int within 10ms of nwake asserting. if the SN260 does not assert nhost_int within 10ms of nwake, it is valid for the host to consider the SN260 unresponsive and to reset the SN260. 5. host detects nhost_int assertion. since the assertion of nhost_int indicates the SN260 can accept spi transactions, the host does not need to hold slave select high for the normally required minimum 1ms of inter-command spacing. 6. host de-asserts nwake after detecting nhost_int assertion. 7. SN260 will de-assert nhost_int within 25s of nwake de-asserting. 8. after 25s, any change on nhost_int will be an indication of a normal asynchronous (callback) event.
SN260 spi protocol 25/88 6.2.7 error conditions if two or more different error co nditions occur back to back, on ly the first error condition will be reported to the host (if it is possible to report the error). the following are error conditions that might occur with the SN260. oversized ezsp frame if the transaction includes an ezsp frame, the length byte cannot be a value greater than 125. if the SN260 detects a length byte greater than 125, it will drop the incoming command and abort th e entire transaction . the SN260 will then assert nhost_int after slave select returns to idle to inform the host through an error code in the response section what has happened. not only is the command in the problematic transaction dropped by the SN260, but the next command is also dropped, because it is responded to with the oversized ezsp frame error response. aborted transaction an aborted transaction is any transaction where slave select returns to idle prematurely and the spi protocol dropped the transaction. the most common reason for slave select returning to idle prematurely is the host unexpectedly resetting. if a transaction is aborted, the SN260 will assert nhost_int to inform the host through an error code in the response section what has happened. when a transaction is aborted, not only does the command in the problematic transaction get dropped by the SN260, but the next command also gets dropped since it is responded to with the aborted transactio n error response. missing frame terminator every command and response must be terminated with the frame terminator byte. the SN260 will drop any command that is missing the frame terminator. the SN260 will then immediately provide the missing frame terminator error response. long transaction a long transaction error occurs when the host clocks too many bytes. as long as the inter-command spacing requirement is met, this error condition should not cause a problem, since the SN260 will send only 0xff outside of the response section as well as ignore incoming bytes outside of the command section. unresponsive unresponsive can mean the SN260 is not powered, not fully booted yet, incorrectly connected to the host, or busy performing other tasks. the host must wait the maximum length of the wait section before it can consider the SN260 unresponsive to the command section. this maximum length is 200 millis econds, measured from the end of the last byte sent in the command section. if the SN260 ever fails to respond during the wait section, it is valid for the host to consider the SN260 unresponsive and to reset the SN260. additionally, if nhos t_int does not assert within 10ms of nwake asserting during the wake handshake, the host can consider the SN260 unresponsive and reset the SN260. 6.3 spi protocol timing figure 6 illustrates all critical timing paramet ers in the spi protocol. these timing parameters are a result of the SN260?s internal operation and both constrain host behavior and characterize SN260 operation. the parameters shown are discussed elsewhere in this document. note that figure 6 is not drawn to scale, but is provided to illust rate where the parameters are measured.
spi protocol SN260 26/88 figure 6. spi protocol timing waveform ta bl e 1 4 lists the timing parameters of the spi pr otocol. these paramete rs are illustrated in figure 6 . 6.4 data format the data format, also referred to as a command , is the same for both the command section and the response section. the data format of the spi protocol is straightforward, as illustrated in figure 7 . figure 7. spi protocol data format the total length of a command must not exceed 128 bytes. all commands must begin with the spi byte . some commands are only two bytes?that is, they contain the spi byte and frame terminator only. table 14. spi protocol timing parameters parameter description min. typ. max. unit t1 (a) wake handshake, while 260 is awake 133 150 s t1 (b) wake handshake, while 260 is asleep 7.3 10 ms t2 wake handshake finish 1.1 1.2 25 s t3 reset pulse width 8 s t4 startup time 250 1500 ms t5 nhost_int de-asserting after command 13 35 75 s t6 clock rate 200 ns t7 wait section 25 755 200000 s t8 nhost_int de-asserting after response 20 130 800 s t9 nhost_int asserting after transaction 25 70 800 s t10 inter-command spacing 1 ms
SN260 spi protocol 27/88 the length byte is only included if there is information in the ezsp frame (emberznet serial protocol frame) and the length byte defines the length of just the ezsp frame. therefore, if a command includes an ezsp frame, the length byte can have a value from 2 through 125 and the overall command size will be 5 through 128 bytes. the spi byte can be a specific value indicating if there is an ezsp frame or not, and if there is an ezsp frame, then the length byte can be expected. the error byte is used by the error responses to provide additional information about the error and appears in place of the length byte. this additional information is described in the following sections. the ezsp frame contains the data needed for operating emberznet. the ezsp frame and its format are explained in section 7: emberznet serial protocol on page 34 . the frame terminator is a special control byte used to mark the end of a command. the frame terminator byte is defined as 0xa7 and is appended to all commands and responses immediately after the final data byte. the purpose of the frame terminator is to provide a known byte the spi protocol can use to detect a corrupt command. for example, if the SN260 resets during the response sectio n, the host will still clock out the correct number of bytes. but when the host attempts to verify the value 0xa7 at the end of the response, it will see either the value 0x00 or 0xff and know that the SN260 just reset and the corrupt response should be discarded. note: the length byte only specifies the length of the ezsp frame. it does not include the frame terminator. 6.5 spi byte ta bl e 1 5 lists the possible commands and their responses in the spi byte. table 15. spi commands & responses command value command response value response any any 0x00 SN260 reset occurred?this is never used in another response; it always indicates an SN260 reset. any any 0x01 oversized ezsp frame received?this is never used in another response; it always indica tes an overflow occurred. any any 0x02 aborted transaction occurred?this is never used in another response; it always indicates an aborted transaction occurred. any any 0x03 missing frame terminator?this is never used in another response; it always i ndicates a missing frame terminator in the command. any any 0x04 reserved 0x00 ? 0x0f reserved [none] [none] 0x0a spi protocol version 0x81 ? 0xbf bit[7] is always set. bit[6] is alwa ys cleared. bit[5:0] is a number from 1?63. 0x0b spi status 0xc0 ? 0xc1 bit[7] is always set. bit[6] is always set. bit[0]?set if alive. 0xf0 ? 0xfd reserved [none] [none] 0xfe ezsp frame 0xfe ezsp frame 0xff invalid 0xff invalid
spi protocol SN260 28/88 6.5.1 primary spi bytes there are three primary spi bytes: spi protocol version, spi status, and ezsp frame. spi protocol version [0x0a] sending this command requests the spi protocol version number from the spi interface. the respon se will always have bit 7 set and bit 6 cleared. in this current version, the response will be 0x81 , because the version number corresponding to this set of command-response values is version number 1. the version number can be a value from 1 to 63 ( 0x81?0xbf ). spi status [0x0b] sending this command asks for the SN260 status. the response status byte will always have the upper 2 bits set. in this current version, the status byte only has one status bit [0], which is set if the SN260 is alive and ready for commands. ezsp frame [0xfe] this byte indicates that the current transaction is an ezsp transaction and there is more data to follow. this spi byte, and onl y this spi byte, will cause the transaction to look like the full data format illustrated in figure 7 . the byte immediately after this spi byte will be a length byte, and it is used to identify the length of the ezsp frame. the ezsp frame is defined in section section 7: emberznet serial protocol on page 34 . if the spi byte is 0xfe , it means the minimum transaction size is five bytes. all other spi bytes mean the transaction size is two or three bytes. 6.5.2 special response bytes there are only five spi byte values, 0x00?0x04 , ever used as error codes (see ta bl e 1 6 ). when the error condit ion occurs, any command sent to the SN260 will be ignored and responded to with one of these codes. these special spi bytes must be trapped and dealt with. in addition, for each error condition the error byte (instead of the length byte) is also sent with the spi byte. table 16. byte values used as error codes spi byte value error message error description error byte description 0x00 SN260 reset see section 6.6: powering on, power cycling, and rebooting . the reset type. refer to the api documentation discussing emberresettype. 0x01 oversized ezsp frame the command contained an ezsp frame with a length byte greater than 125. the SN260 was forced to drop the entire command. reserved 0x02 aborted transaction the transaction was not completed properly and the SN260 was forced to abort the transaction. reserved 0x03 missing frame terminator the command was missing the frame terminator. the SN260 was forced to drop the entire command. reserved 0x04 reserved [none] [none]
SN260 spi protocol 29/88 6.6 powering on, power cycling, and rebooting when the host powers on (or reboots), it cannot guarantee that the SN260 is awake and ready to receive commands. therefore, the host should always perform the wake SN260 handshake to guarantee that the SN260 is awake. if the SN260 resets, it needs to inform the host so that the host can reconfigure the stack if needed. when the SN260 resets, it will assert the nhos t_int signal, telling the host that it has data. the host should reques t data from the SN260 as usual. the sn 260 will ignore whatever command is sent to it and respond only with two bytes. the first byte will always be 0x00 and the second byte will be t he reset type as defined by emberresettype . this specialty spi byte is never used in anot her response spi byte. if the host sees 0x00 from the SN260, it knows that the SN260 ha s been reset. the SN260 will de-assert the nhost_int signal shortly after receiving a byte on the spi and process all further commands in the usual manner. in addition to the host having control of the reset line of the SN260, the emberznet serial protocol also provides a mechanism for a software reboot. 6.6.1 unexpected resets the SN260 is designed to protect itself against undefined behavior due to unexpected resets. the protection is based on the state of slave select since the inter-command spacing mandates that slave select must return to idle. the SN260?s internal spi protocol uses slave select returning to idle as a trigger to re-initialize its spi protocol. by always re- initializing, the SN260 is protected against the host unexpectedly resetting or terminating a transaction. additionally, if slave select is ac tive when the SN260 powers on, the SN260 will ignore spi data until slave select returns to idle. by ignoring spi traffic until idle, the SN260 will not begin receiving in th e middle of a transaction. if the host resets, in most cases it should reset the SN260 as well so that both devices are once again in the same state: freshly booted. alternately, the host can attempt to recover from the reset by recovering its previous state and resynchronizing with the state of the SN260. if the SN260 resets during a transaction, the host can expect either a wait section timeout or a missing frame terminator indicating an invalid response. if the SN260 resets outside of a transaction, the host should proceed normally. 6.7 transaction examples this section contains the following transaction examples: spi protocol version emberznet serial protocol frame ? nop command SN260 reset three-part transaction: wake, get version, stack status callback
spi protocol SN260 30/88 6.7.1 spi protocol version figure 8. spi protocol version example 1. activate slave select (nssel). 2. transmit the command 0x0a - spi protocol version request. 3. transmit the frame terminator, 0xa7 . 4. wait for nhost_int to assert. 5. transmit and receive 0xff until a byte other than 0xff is received. 6. receive response 0x81 (a byte other than 0xff ), then receive the frame terminator, 0xa7 . 7. bit 7 is always set and bit 6 is always cl eared in the version response, so this is version 1. 8. de-activate slave select. 6.7.2 emberznet serial pr otocol frame ? nop command figure 9. emberznet serial protocol frame - nop command example 1. activate slave select (nssel). 2. transmit the appropriate command: ? 0xfe : spi byte indicating an ezsp frame ? 0x02 : length byte showing the ezsp frame is 2 bytes long ? 0x00 : ezsp frame control byte indicating a command with no sleeping ? 0x05 : ezsp frame type byte indicating the nop command ? 0xa7 : frame terminator 3. wait for nhost_int to assert. 4. transmit and receive 0xff until a byte other than 0xff is received. 5. receive response 0xfe (a byte other than 0xff ) and read the next byte for a length.
SN260 spi protocol 31/88 6. stop transmitting after the number of bytes (length) is received plus the frame te r m i n a t o r. 7. decode the response: ? 0xfe : spi byte indicating an ezsp frame ? 0x02 : length byte showing the ezsp frame is 2 bytes long ? 0x80 : ezsp frame control byte indicating a response with no overflow ? 0x05 : ezsp frame type byte indicating the nop response ? 0xa7 : frame terminator 8. de-activate slave select. 6.7.3 SN260 reset figure 10. SN260 reset example 1. nhost_int asserts. 2. activate slave select (nssel). 3. transmit the command: ? 0xfe : spi byte indicating an ezsp frame ? 0x02 : length byte showing the ezsp frame is 2 bytes long ? 0x00 : ezsp frame control byte indicating a command with no sleeping ? 0x06 : ezsp frame type byte indicating the callback command ? 0xa7 : frame terminator 4. wait for nhost_int to assert. 5. transmit and receive 0xff until a byte other than 0xff is received. 6. receive response 0x00 (a byte other than 0xff ). 7. receive the error byte and decode ( 0x02 is enumerated as reset_poweron). 8. receive the frame terminator ( 0xa7 ). 9. response 0x00 indicates the SN260 has reset and the host should respond appropriately. 10. deactivate slave select. 11. since nhost_int does not assert again, there is no more data for the host.
spi protocol SN260 32/88 6.7.4 three-part transaction: wake, get version, stack status callback figure 11. timing diagram of the three-part transaction 1. activate nwake and activate timeout timer. 2. SN260 wakes up (if not already) awake and enables communication. 3. nhost_int asserts, indicating the SN260 can accept commands. 4. host sees nhost_ int activation within 10ms an d deactivates nw ake and timeout timer. 5. nhost_int de-asserts immediately after nwake. 6. activate slave select. 7. transmit the command 0x0a - spi protocol version request. 8. transmit the frame terminator, 0xa7 . 9. wait for nhost_int to assert. 10. transmit and receive 0xff until a byte other than 0xff is received. 11. receive response 0x81 (a byte other than 0xff ), then receive the frame terminator, 0xa7 . 12. bit 7 is always set and bit 6 is always cl eared in the version response, so this is version 1. 13. deactivate slave select. 14. host begins timing the inter-command spacing of 1ms in preparation for sending the next command. 15. nhost_int asserts shortly after deactivating slave select, indicating a callback. 16. host sees nhost_int, but waits for the 1ms before responding. 17. activate slave select. 18. transmit the command: ? 0xfe : spi byte indicating an ezsp frame ? 0x02 : length byte showing the ezsp frame is 2 bytes long ? 0x00 : ezsp frame control byte indicating a command with no sleeping ? 0x06 : ezsp frame type byte indicating the callback command ? 0xa7 : frame terminator 19. wait for nhost_int to assert. 20. transmit and receive 0xff until a byte other than 0xff is received. 21. receive response 0xfe (a byte other than 0xff ), read the next byte for a length. 22. stop transmitting after the number of bytes (length) is received plus the frame te r m i n a t o r.
SN260 spi protocol 33/88 23. decode the response: ? 0xfe : spi byte indicating an ezsp frame ? 0x03 : length byte showing the ezsp frame is 3 bytes long ? 0x80 : ezsp frame control byte indicating a response with no overflow ? 0x19 : ezsp frame type byte indicating the emberstackstatushandler command ? 0x91 : emberstatus ember_network_down from emberstackstatushandler ? 0xa7 ? frame terminator 24. deactivate slave select. 25. since nhost_int does not assert again, there is no more data for the host.
emberznet serial protocol SN260 34/88 7 emberznet serial protocol emberznet serial protocol (ezsp)has been design ed to be very familiar r to customers who have used the emberznet 2.x stack api. the majority of the commands and responses are functionally identical to those found in emberznet 2.x. the variations are due mainly to the timing differences of running the application on a separate processor across a serial interface. communication between the SN260 and the host consists of a two-message transaction. the host sends a command message to the SN260 and then the SN260 sends a response message to the host. if the SN260 needs to communicate asynchronously with the host, it will indicate this by using the inte rrupt line and then waiting for the host to send the callback command. all ezsp frames begin with a frame control byte followed by a frame id byte. the format of the rest of the frame depends on the frame id. section 7.3: protocol format on page 38 defines the format for all the frame ids. most of the frames have a fixed length. a few, such as those containing application messages, are of variable length. the frame control indicates the direction of the message (command or response). for commands, the frame control also contains power management information, and for responses it also contains status information. when a command contains an application message, the host must supply a one-byte tag. this tag is used in future commands and responses to refer to the message. for example, when sending a message, the host provides both the message contents and a tag. the tag is then used to report the fate of the message in a later response from the SN260. 7.1 byte order all multiple octet fields are transmitted and received with the least significant octet first, also referred to as little endian. this is the same byte order convention specified by 802.15.4 and zigbee. note that eui64 fields are treated as a 64-bit number and are therefore transmitted and received in little endian order. each individual octet is transmitted with the most significant bit first, as shown in section 6.1: physical interface configuration on page 22 . 7.2 conceptual overview this section provides an overview of the conc epts that are specific to the SN260 or that differ from the emberznet 2.x stack api. the commands and responses mentioned in this overview are described in more detail later in this document. 7.2.1 stack configuration the host can use the version command to obtain information about the firmware running on the SN260. there are a number of configuration values that affect the behavior of the stack. the host can read these values at any time using the getconfigurationvalue command. after the SN260 has reset, the host can modify any of the default values using the setconfigurationvalue command. the host must then provide information about the application endpoints using the addendpoint command. ta bl e 1 7 gives the minimum, default and maximum values for each of the configuration values. also listed is the ram cost. this is t he number of bytes of additional ram required to increase the configuration value by one. since the total amount of ram is fixed, the
SN260 emberznet serial protocol 35/88 additional ram required must be made available by reducing one of the other configuration values. table 17. configuration values value min. def. max. units ram cost description ezsp_config_packet_buffer_ count 524 packet buffers 40 the number of packet buffers available to the stack. ezsp_config_neighbor_table_ size 8 16 16 neighbors 18 the maximum number of router neighbors the stack can keep track of. a neighbor is a node within radio range. ezsp_config_transport_ packet_count 0 10 messages 10 the maximum number of datagram and sequenced messages the stack can have in the process of being either transmitted or received at any given time. ezsp_config_binding_ table_size (a) 08 32 + (b) entries 3 the maximum number of bindings supported by the stack. it includes the bindings in eeprom and in ram. ezsp_config_temporary_ binding_entries (b) 0 8 (a) entries 12 the number of binding table entries in ram. ezsp_config_transport_ connection_count 00 entries12 the number of binding table entries that can concurrently support an open sequenced connection. ezsp_config_route_ table_size (c) 016 entries 6 the maximum number of destinations to which a node can route messages. this include both messages originating at this node and those relayed for others. ezsp_config_discovery_ table_size 08 entries10 the number of simultane ous route discoveries that a node will support. ezsp_config_discovery_ cache_endpoints (d) 0 4 endpoints 0 end-device child endpoints larger than this value will not have their discovery information cached by their router parent. ezsp_config_discovery_ cache_entry_size 11 + (d) 15 15 bytes 0 the size of an entry in the end device discovery cache on a router. endpoint descriptions longer t han this will not be cached. ezsp_config_discovery_ cache_size 03535entries 0 the number of entries in the discovery cache on a router. each end device child requires 1 + (d) entries. the cache is held in eeprom. ezsp_config_stack_profile 0 0 0 specifies the stack profile. ezsp_config_security_level 055 0 the security level used for security at the mac and network layers. the supported values are 0 (no security) and 5 (payload is encrypted and a four-byte mic is used for authentication). ezsp_config_max_hops 0 10 hops 0 the maximum number of hops for a message. ezsp_config_max_end_device_ children (e) 0 6 32 children 4 the maximum number of end device children that a router will support. ezsp_config_indirect_ transmission_timeout 0 3000 30000 milli- seconds 0 the maximum amount of time that the mac will hold a message for i ndirect transmission to a child.
emberznet serial protocol SN260 36/88 7.2.2 policy settings there are some situations when the SN260 must make a decision but there isn?t enough time to consult with the host. the host can control what decision is made by setting the policy in advance. the SN260 will then make decisions according to the current policy. the host is informed via callbacks each time a decision is made, but by the time the news reaches the host, it is too late to change that decision. you can change the policies at any time by using the setpolicy command. a policy is used for trust center behavior, external binding modification requests, datagram replies, generating pollhandler callbacks, and the contents of the unicastsent and messagesent callbacks. 7.2.3 datagram replies the policy for datagram replies allows the host to decide whether it wants to supply the SN260 with a reply payload for every datagram received. if the host sets the policy to not supply a reply, the SN260 will automatically send an empty r eply (containing no payload) for every datagram received. if the host sets the policy to supply the reply, then the SN260 will only send a reply when instructed by the host. if the reply does not reach the sender before the transport retry timeout expires, the sender will transmit the datagram again. the host must process the incoming message and supply the reply quickly enough to avoid retransmission by the sender. provided this timing constraint is met, multiple datagrams can be received before the first reply is supplied and the replies can be supplied in any order. 7.2.4 callbacks asynchronous callbacks from the SN260 are sent to the host as the response to a callback command. the SN260 uses the interrupt line to indicate that the host should send a callback command. the SN260 will que ue multiple callbacks while it waits for the host, and each response only delivers one callback. if the SN260 receives the callback command when there are no pending callbacks, it will reply with the nocallbacks response. ezsp_config_reserved_ routing_entries 00(c)entries0 the number of route table entries that are reserved for temporary aggregation routes in the mesh stack. ezsp_config_mobile_node_ poll_timeout 020 quarter seconds 0 the maximum amount of time that a mobile node can wait between polls. if no poll is heard within this timeout, then the parent removes the mobile node from its tables. ezsp_config_reserved_ mobile_child_entries 00(e)entries0 the number of child table entries reserved for use only by mobile nodes. ezsp_config_host_ram 0 0 255 bytes 1 the amount of ram available for use by the host. ezsp_config_tx_power_mode 003 0 enables boost power mode and/or the alternate transmitter output. table 17. configuration values (continued) value min. def. max. units ram cost description
SN260 emberznet serial protocol 37/88 7.2.5 power management the SN260 will always idle its processor w henever possible. to further reduce power consumption, the SN260 can be put to sleep by the host. in power down mode, only an external interrupt will wake the SN260. in dee p sleep mode, the SN260 will use its internal timer to wake up for scheduled events. the SN260 provides two independent timers that the host can use for any purpose, including waking up the SN260 from deep sleep mode. timers are set using the settimer command and generate timerhandler callbacks. the initial frame control byte of every command tells the SN260 which sleep mode to enter after it has responded to the command. including this information in every command (instead of having a separate power management command) allows the SN260 to be put to sleep faster. if the host needs to put the SN260 to sleep without also performing another action, the nop command can be used. in deep sleep mode, the sn26 0 will wake up for an internal event. if the event does not produce a callback for the host , the SN260 will go back to sl eep once the ev ent has been handled. if the event does prod uce a callback, the SN260 will signal the host and remain awake waiting for the callback command. if the frame control byte of the callback command specifies deep sleep mode, then the SN260 would normally go back to sleep after responding with the callback. however, if ther e is a second callback pending, the SN260 will remain awake waiting for another callback command. to avoid disrupting the operation of the network, only put the SN260 to sleep when it is not joined to a network or when it is joined as a sleeping end device. if the SN260 is joined as a sleeping end device, then it must poll its parent in order to receive messages. the host controls the polling behavior using the pollfordata command. polls are sent periodically with the interval set by the host or a single poll can be sent. the result of every poll attempt is optionally reported using the pollcompletehandler callback. 7.2.6 tokens some of the non-volatile storage on the SN260 is made available for use by the host. up to 8 manufacturing tokens stored in the flash information area can be read using the getmfgtoken command and up to 8 to kens stored in the simu lated eeprom can be read and written using the settoken and gettoken commands. each token is 8 bytes. tokens preserve their values between reboots. refer to section simulated eeprom for a description of the simulated eepr om and write cycle estimates. 7.2.7 ram some of the ram on the SN260 can be reserved by the host for its own use. the amount of space reserved is the ezsp_config_host_ram configuration value (set using the setconfigurationvalue command). the host can then read and write data using the setram and getram commands. if the host chooses to reserve ram, this will reduce the number of messages and callbacks that the SN260 can buffer.
emberznet serial protocol SN260 38/88 7.2.8 SN260 status the frame control byte of every response sent by the SN260 contains two status bits: the overflow bit is set if the SN260 ran out of memory at any time since the previous response was sent. if this bit is set, then messages may have been lost. the truncated bit is set if the SN260 truncated the current response. if this bit is set, the command from the host produced a response larger than the maximum ezsp frame length. you can use the nop command to check the status of the SN260 without also performing another action. 7.2.9 random number generator the host can obtain a random number from the SN260 using the getrandomnumber command. the random number is generated from analog noise in the radio and can be used to seed a random number generator on the host. 7.3 protocol format all ezsp frames begin with a frame control byte. ta bl e 1 8 describes the meaning of this byte for command and response frames. ta b l e 1 9 describes the sleep modes, ta bl e 2 0 describes the overflow status bit and ta b l e 2 1 describes the truncated status bit. the second byte of all ezsp frames is the frame id byte. table 18. frame control byte bit command response 7 (msb) 0 1 6 0 (reserved) 0 (reserved) 5 0 (reserved) 0 (reserved) 4 0 (reserved) 0 (reserved) 3 0 (reserved) 0 (reserved) 2 0 (reserved) 0 (reserved) 1 sleepmode[1] truncated 0 (lsb) sleepmode[0] overflow table 19. sleep modes sleepmode[1] sleepmode[0] description 1 1 reserved. 10 power down. 0 1 deep sleep. 00 idle.
SN260 emberznet serial protocol 39/88 section 7.3.1: type definitions defines all the types used by the SN260 and section 7.3.2: structure definitions defines all the structures. section 7.3.3: named values enumerates all the named values for the different types. the subsequent sections list all the frames supported by the SN260, specifying the frame id, the command parameters and the response parameters. the list is divided into five sections: section 7.3.4 lists configuration frames. section 7.3.5 lists utilities frames. section 7.3.6 lists networking frames. section 7.3.7 lists binding frames. section 7.3.8 lists messaging frames. finally, section section 7.3.9 provides an alphabetical list of all the frames. table 20. overflow status overflow description 1 the SN260 ran out of memory since the previous response. 0 no memory shortage since the previous response. table 21. truncated status truncated description 1 the SN260 truncated the current res ponse to avoid exceeding the maximum ezsp frame length. 0 the current response was not truncated.
emberznet serial protocol SN260 40/88 7.3.1 type definitions table 22. type definitions type alias description boolean int8u true or false. ezspconfigid int8u identifies a configuration value. ezspconfigtxpowermode int16u values for ezsp_ config_tx_power_mode. ezspconfigstatus int8u return type for configuration commands. ezsppolicyid int8u identifies a policy. ezspdecisionid int8u identifies a policy decision. emberstatus int8u return type for stack functions. embereventunits int8u either marks an event as inactive or specifies the units for the event execution time. embernodetype int8u the type of the node. embernetworkstatus int8u the possible join states for a node. emberincomingmessagetype int8u incoming message types. emberbindingtype int8u binding types. emberunicastoption int8u options to use when sending a unicast message. embernetworkscantype int8u network scan types. emberjoindecision int8u decision made by the trust center when a node attempts to join. embernodeid int16u 16-bit zigbee network address. emberpanid int16u 802.15.4 pan id. embereui64 int8u[8] eui 64-bit id (an ieee address).
SN260 emberznet serial protocol 41/88 7.3.2 structure definitions table 23. structure definitions structure field description embernetworkparameters network parameters. int16u panid the network's pan identifier. int8s radiotxpower a power setting, in dbm. int8u radiochannel a radio channel. emberapsframe zigbee aps frame parameters. int16u profileid the application profile id that describes the format of the message. int8u clusterid the cluster id for this message. int8u sourceendpoint the source endpoint. int8u destinationendpoint the destination endpoint. emberunicastoption options a bitmask of options. emberbindingtableentry an entry in the binding table. emberbindingtype type the type of binding. int8u local the endpoint on the local node. int8u remote the endpoint on the remote node (specified by identifier). int8u clusterid a cluster id that matches one from the local endpoint's simple descriptor. this cl uster id is set by the provisioning application to indicate which part an endpoint's functionality is bound to this particular remote node and is used to distinguish between unicast and multicast bindings. a binding can be used to send messages with any cluster id, not just the one listed in the binding. embereui64 identifier a 64-bit identifier. this is either the destination eui64 (for unicasts) or the 64-bit group address (for multicasts).
emberznet serial protocol SN260 42/88 7.3.3 named values table 24. boolean structure field description false 0x00 an alias for zero, used for clarity. true 0x01 an alias for one, used for clarity. table 25. ezspconfigid structure field description ezsp_config_packet_buffer_count 0x01 the number of packet buffers available to the stack. ezsp_config_neighbor_table_size 0x02 the maximum number of router neighbors the stack can keep track of. a neighbor is a node within radio range. ezsp_config_transport_packet_coun t 0x03 the maximum number of datagram and sequenced messages the stack can have 'in-flight' at any time. here, 'in-flight' means 'in the process of being either transmitted or received'. ezsp_config_binding_table_size 0x04 the maximum number of bindings supported by the stack. it includes the bindings in eeprom and in ram. ezsp_config_temporary_binding_ent ries 0x05 the number of binding table entries in ram. ezsp_config_transport_connection_ count 0x06 the number of binding table entries that can concurrently support an open sequenced connection. ezsp_config_route_table_size 0x07 the maximum number of destinations to which a node can route messages. this include both messages originating at this node and those relayed for others. ezsp_config_discovery_table_size 0x08 the number of simultaneous route discoveries that a node will support. ezsp_config_discovery_cache_endpo ints 0x09 end-device child endpoints larger than this value will not have their discovery information cached by their router parent. ezsp_config_discovery_cache_entry _size 0x0a the size of an entry in the end device discovery cache on a router. endpoint descriptions longer than this will not be cached. ezsp_config_discovery_cache_size 0x0b the number of entries in the discovery cache on a router. each end device child requires 1 + ezsp_config_discover y_cache_endpoints entries. the cache is held in eeprom. ezsp_config_stack_profile 0x0c specifies the stack profile. ezsp_config_security_level 0x0d the security level used for security at the mac and network layers. the supported values are 0 (no security) and 5 (payload is encrypted and a four-byte mic is used for authentication). ezsp_config_max_hops 0x10 the maximum number of hops for a message. ezsp_config_max_end_device_childr en 0x11 the maximum number of end device children that a router will support.
SN260 emberznet serial protocol 43/88 ezsp_config_indirect_transmission timeout 0x12 the maximum amount of time that the mac will hold a message for indirect transmission to a child. ezsp_config_reserved_routing_ entries 0x13 the number of route table entries that are reserved for temporary aggregation routes in the mesh stack. ezsp_config_mobile_node_poll_ timeout 0x14 the maximum amount of time that a mobile node can wait between polls. if no poll is heard within this timeout, then the parent removes the mobile node from its tables. ezsp_config_reserved_mobile_child entries 0x15 the number of child table entries reserved for use only by mobile nodes. ezsp_config_host_ram 0x16 the amount of ram available for use by the host. ezsp_config_tx_power_mode 0x17 enables boost power mode and/or the alternate transmitter output. table 25. ezspconfigid (continued) structure field description table 26. ezspconfigtxpowermode structure field description ember_tx_power_mode_default 0x00 normal power mode and bi-directional rf transmitter output. ember_tx_power_mode_boost 0x01 enable boost power mode. this is a high performance radio mode which offers increased receive sensitivity and transmit power at the cost of an increase in power consumption. ember_tx_power_mode_alternate 0x02 enable the alternate transmitter output. this allows for simplified connection to an external power amplifier via the rf_tx_alt_p and rf_tx_alt_n pins. ember_tx_power_mode_boost_and_ alternate 0x03 enable both boost mode and the alternate transmitter output. table 27. ezspconfigstatus structure field description ezsp_config_success 0x00 the command was successful. ezsp_config_out_of_memory 0x01 insufficient memory was available. ezsp_config_invalid_value 0x02 the value was out of bounds. ezsp_config_invalid_tag 0x03 the configuration tag was not recognized. ezsp_config_invalid_call 0x04 configuration values can no longer be modified. table 28. ezsppolicyid structure field description ezsp_trust_center_policy 0x00 controls trust center behavior. ezsp_binding_modification_policy 0x01 controls how external binding modification requests are handled. ezsp_datagram_replies_policy 0x02 controls whether the host supplies datagram replies.
emberznet serial protocol SN260 44/88 ezsp_poll_handler_policy 0x03 controls whether pollhandler callbacks are generated. ezsp_message_contents_in_callback _policy 0x04 controls whether the message contents are included in unicastsent and messagesent callbacks. table 28. ezsppolicyid (continued) structure field description table 29. ezspdecisionid structure field description ezsp_allow_secure_joins_only 0x00 ezsp_trust_center_policy default decision. only allow nodes that are joining securely using the network key to join. ezsp_allow_all_joins 0x01 ezsp_trust_center_policy decision. allow all nodes to join, sending the key to nodes that are not joining securely. ezsp_disallow_all_joins 0x02 ezsp_trust_center_policy decision. reject all join attempts. ezsp_ask_trust_center 0x03 ezsp_trust_center_policy decision. forward the request to the trust center (this value should not be used for the trust center itself). ezsp_disallow_binding_modificatio n 0x10 ezsp_binding_modificat ion_policy default decision. do not allow the local binding table to be changed by remote nodes. ezsp_allow_binding_modification 0x11 ezsp_binding_modificatio n_policy decision. allow remote nodes to change the local binding table. ezsp_host_will_not_supply_reply 0x20 ezsp_datagram_replies_policy default decision. the SN260 will automatically send an empty reply (containing no payload) for every datagram received. ezsp_host_will_supply_reply 0x21 ezsp_datagram_replies_policy decision. the SN260 will only send a reply if it receives a sendreply command from the host. ezsp_poll_handler_ignore 0x30 ezsp_poll_handler_policy default decision. do not inform the host when a child polls. ezsp_poll_handler_callback 0x31 ezsp_poll_handler_policy decision. generate a pollhandler callback when a child polls. ezsp_message_tag_only_in_callback 0x40 ezsp_message_contents_in_callback_policy default decision. include only the message tag in unicastsent and messagesent callbacks. ezsp_message_tag_and_contents_in_ callback 0x41 ezsp_message_contents_in_callback_policy decision. include both t he message tag and the message contents in unicastsent and messagesent callbacks.
SN260 emberznet serial protocol 45/88 table 30. emberstatus structure field description ember_success 0x00 generic 'no error' message. ember_err_fatal 0x01 generic 'fatal error' message. ember_eeprom_mfg_stack_version_ mismatch 0x04 manufacturing and stack token format in non-volatile memory is different than what the stack expects (returned at initialization). ember_incompatible_static_memory_ definitions 0x05 static memory definitions in ember-static-memory.h are incompatible with this stack version. ember_eeprom_mfg_version_mismatch 0x06 manufacturing token format in non-volatile memory is different than what the st ack expects (returned at initialization). ember_eeprom_stack_version_ mismatch 0x07 stack token format in non-volatile memory is different than what the stack expects (returned at initialization). ember_no_buffers 0x18 there are no more buffers. ember_serial_invalid_baud_rate 0x20 specified an invalid baud rate. ember_serial_invalid_port 0x21 specified an invalid serial port. ember_serial_tx_overflow 0x22 tried to send too much data. ember_serial_rx_overflow 0x23 there was not enough space to store a received character and the character was dropped. ember_serial_rx_frame_error 0x24 detected a uart framing error. ember_serial_rx_parity_error 0x25 detected a uart parity error. ember_serial_rx_empty 0x26 there is no received data to process. ember_serial_rx_overrun_error 0x27 receive interrupt was not handled in time, and a character was dropped. ember_mac_transmit_queue_full 0x39 mac transmit queue is full. ember_mac_unknown_header_type 0x3a mac header fcr error on receive. ember_mac_scanning 0x3d mac can't complete this task because it is scanning. ember_mac_no_data 0x31 no pending data exists for device doing a data poll. ember_mac_joined_network 0x32 attempt to scan when we are joined to a network. ember_mac_bad_scan_duration 0x33 scan duration must be 0 to 14 inclusive. attempt was made to scan with an incorrect duration value. ember_mac_incorrect_scan_type 0x34 emberstartscan was called with an incorrect scan type. ember_mac_invalid_channel_mask 0x35 emberstartscan was called with an invalid channel mask. ember_mac_command_transmit_ failure 0x36 failed to scan current channel because we were unable to transmit the relevant mac command. ember_mac_no_ack_received 0x40 we expected to receive an ack following the transmission, but the mac level ack was never received. ember_mac_indirect_timeout 0x42 indirect data message timed out before polled.
emberznet serial protocol SN260 46/88 ember_sim_eeprom_erase_page_green 0x43 simulated eeprom is telling t he application that there is at least one flash page to be erased. green status means the current page has not filled above the erase_critical_threshold . the application should call the function halsimeepromerasepage () when it can to erase a page. ember_sim_eeprom_erase_page_red 0x44 simulated eeprom is telling t he application that there is at least one flash page to be erased. red status means the current page has filled above the erase_critical_threshold . due to the shrinking availability of write space, t here is a danger of data loss. the application must call the function halsimeepromerasepage() as soon as possible to erase a page. ember_sim_eeprom_full 0x45 simulated eeprom has run out of room to write any new data and the data trying to be set has been lost. this error code is the result of ignoring the sim_eeprom_erase_page_red error code. the application must call the function halsimeepromerasepage() to make room for any further calls to set a token. ember_sim_eeprom_flash_write_ failed 0x46 a fatal error has occurred while trying to write data to the flash and the write verification has failed. the data in the flash cannot be trusted after this error, and it is possible this error is the result of exceeding the life cycles of the flash. ember_sim_eeprom_init_1_failed 0x47 attempt 1 to initialize the simulated eeprom has failed. this failure means the information already stored in flash (or a lack thereof), is fatally incompatible with the token information compiled into the code image being run. ember_sim_eeprom_init_2_failed 0x48 attempt 2 to initialize the simulated eeprom has failed. this failure means attemp t 1 failed, and the token system failed to properly reload default tokens and reset the simulated eeprom. ember_sim_eeprom_init_3_failed 0x49 attempt 3 to initialize the simulated eeprom has failed. this failure means one or both of the tokens token_mfg_nvdata_version or token_stack_nvdata_version were incorrect and the token system failed to properly reload default tokens and reset the simulated eeprom. ember_err_token_unknown 0x4b an unknown flash token was specified. ember_err_token_exists 0x4c could not create new flash token because it already exists. ember_err_token_invalid_size 0x4d an incorrect size was specif ied when retrieving token data. ember_err_token_read_only 0x4e couldn't write token bec ause it is marked read-only. ember_err_bootloader_trap_ table_bad 0x58 bootloader received an invalid message (failed attempt to go into bootloader). table 30. emberstatus (continued) structure field description
SN260 emberznet serial protocol 47/88 ember_err_bootloader_trap_unknown 0x59 bootloader received an invalid message (failed attempt to go into bootloader). ember_err_bootloader_no_image 0x5a bootloader cannot complete the bootload operation because either an image was not found or the image exceeded memory bounds. ember_too_many_connections 0x60 ember_transport_connection_count limit has been reached. ember_connection_open 0x61 a connection has either been opened or is already open. ember_connection_failed 0x63 a connection experienced a catastrophic error. the connection is now closed and messages may have been lost. ember_connection_closed 0x64 transport layer successfully closed a connection. ember_connection_closing 0x65 transport layer is in process of closing a connection (waiting for a response from the remote device). ember_delivery_failed 0x66 transport layer attempted to send or deliver a message, but it failed. ember_binding_index_out_of_range 0x69 this binding index is out of range of the current binding table. ember_invalid_binding_terminal 0x6b could not set or find a binding index given the specified terminal. ember_invalid_binding_index 0x6c an invalid binding table index was given to a function. ember_terminal_has_multiple_ bindings 0x6f multiple binding table entries were found for the specified terminal. ember_invalid_call 0x70 api call is not allowed given the current state of the stack (for example, opening a connection from a sleepy node.). ember_cost_not_known 0x71 link cost to a node is not known. ember_max_message_limit_reached 0x72 maximum number of in-flight messages (such as ember_transport_packet_count ) has been reached. ember_connection_not_yet_open 0x73 a connection is not open yet. ember_message_too_long 0x74 message to be transmitted is too big to fit into a single over-the-air packet. ember_binding_is_active 0x75 application is trying to delete or overwrite a binding that is in use. ember_eui64_not_available 0x76 eui64 is not available in the current packet. ember_incoming_sequenced_messages lost 0x77 one or more sequenced messages failed to be received. ember_adc_conversion_done 0x80 conversion is complete. ember_adc_conversion_busy 0x81 conversion cannot be done because a request is being processed. ember_adc_conversion_deferred 0x82 conversion is deferred until the current request has been processed. ember_adc_no_conversion_pending 0x84 no results are pending. table 30. emberstatus (continued) structure field description
emberznet serial protocol SN260 48/88 ember_sleep_interrupted 0x85 sleeping (for a duration) has been abnormally interrupted and exited prematurely. ember_phy_tx_underflow 0x88 transmit hardware buffer underflowed. ember_phy_tx_incomplete 0x89 transmit hardware did not finish transmitting a packet. ember_phy_invalid_channel 0x8a an unsupported channel setting was specified. ember_phy_invalid_power 0x8b an unsupported power setting was specified. ember_phy_tx_busy 0x8c packet cannot be transmitted because the physical mac layer is currently transmitting a packet. (this is used for the mac backoff algorithm.) ember_phy_unknown_radio_type 0x8d the software installed on the hardware doesn't recognize the hardware radio type. ember_phy_oscillator_check_failed 0x8e the software installed on the hardware doesn't recognize the hardware radio type. ember_phy_partial_packet 0x8f phy did not receive the entire packet it was expecting from the radio. ember_network_up 0x90 stack software has completed initialization and is ready to send and receive packets over the air. ember_network_down 0x91 network is not operating. ember_network_pending_activity 0x92 network has activity pending and should not be shut down. ember_not_joined 0x93 node has not joined a network. ember_join_failed 0x94 an attempt to join a network failed. ember_invalid_security_level 0x95 the chosen security level (the value of ember_security_level ) is not supported by the stack. ember_move_failed 0x96 after moving, a mobile node's attempt to re-establish contact with the network failed. ember_network_busy 0xa1 a message cannot be sent because the network is currently overloaded. ember_nodeid_invalid 0xa2 a datagram was sent to a node and the eui64 address in the datagram did not match the node's eui64 address. the nodeid was invalid. ember_invalid_endpoint 0xa3 the application tried to send a message using an endpoint that it has not defined. ember_binding_has_changed 0xa4 the application tried to use a binding that has been remotely modified and the change has not yet been reported to the application. ember_stack_and_hardware_mismatch 0xb0 a critical and fatal error indicating that the version of the stack trying to run does not match with the chip it is running on. the software (stack) on the chip must be replaced with software that is compatible with the chip. table 30. emberstatus (continued) structure field description
SN260 emberznet serial protocol 49/88 table 31. embereventunits structure field description ember_event_inactive 0x00 event is not scheduled to run. ember_event_ms_time 0x01 execution time is in approximate milliseconds. ember_event_qs_time 0x02 execution time is in 'binary' quarter seconds (256 approximate milliseconds each). ember_event_minute_time 0x03 execution time is in 'binary' minutes (65536 approximate milliseconds each). table 32. embernodetype structure field description ember_coordinator 0x01 will relay messages and can act as a parent to other nodes. ember_router 0x02 will relay messages and can act as a parent to other nodes. ember_end_device 0x03 communicates only with its parent and will not relay messages. ember_sleepy_end_device 0x04 an end device whose radio can be turned off to save power. the application must poll to receive messages. ember_mobile_end_device 0x05 a sleepy end device that can move through the network. table 33. embernetworkstatus structure field description ember_no_network 0x00 the node is not associated with a network in any way. ember_joining_network 0x01 the node is currently attempting to join a network. ember_joined_network 0x02 the node is joined to a network. ember_joined_network_no_parent 0x03 the node is an end device joined to a network but its parent is not responding. ember_leaving_network 0x04 the node is in the process of leaving its current network. table 34. emberincomingmessagetype structure field description ember_incoming_datagram 0x00 datagram. ember_incoming_datagram_reply 0x01 datagram reply. ember_incoming_sequenced 0x02 sequenced message. ember_incoming_multicast 0x03 multicast. ember_incoming_shared_multicast 0x04 shared multicast. ember_incoming_multicast_loopback 0x05 multicast loopback. 333ember_incoming_unicast 0x06 unicast. ember_incoming_broadcast 0x07 broadcast.
emberznet serial protocol SN260 50/88 table 35. emberbindingtype structure field description ember_unused_binding 0x00 a binding that is currently not in use. ember_unicast_binding 0x01 a unicast binding whose 64-bit identifier is the destination eui64. ember_aggregation_binding 0x02 a unicast binding whose 64-bit identifier is the aggregator eui64. ember_multicast_binding 0x03 a multicast binding whose 64-bit identifier is the group address. a multicast binding can be used to send messages to the group and to receive messages sent to the group. table 36. emberunicastoption structure field description ember_unicast_option_none 0x00 no options. ember_unicast_option_aps_indirect 0x04 reserved. ember_unicast_option_have_source 0x10 reserved. ember_unicast_option_aps_retry 0x40 resend the message usin g the aps retry mechanism. ember_unicast_option_enable_route discovery 0x80 causes a route discovery to be initiated if no route to the destination is known. ember_unicast_option_force_route_ discovery 0x20 causes a route discovery to be initiated even if one is known. ember_unicast_option_poll_ response 0x01 reserved. table 37. embernetworkscantype structure field description ember_energy_scan 0x00 an energy scan scans each channel for its rssi value. ember_active_scan 0x01 an active scan scans each channel for available networks. table 38. emberjoindecision structure field description ember_has_key 0x00 allow the node to join. the node has the key. ember_send_key 0x01 allow the node to join. send the key to the node. ember_deny_join 0x02 deny join. ember_ask_trust_center 0x03 ask the trust center.
SN260 emberznet serial protocol 51/88 7.3.4 configuration frames table 39. version name: version id: 0x00 description: the command allows the host to specify the desired ez sp version. this document describes version 1 of the protocol. the response provides informat ion about the firmware running on the SN260. command parameters: int8u desiredprotocolversion the ezsp version the host wishes to use. response parameters: int8u protocolversion the ezsp version the SN260 is using. if the SN260 does not support the version requested by the host, it will use the highest version it does support. int8u stacktype the type of stack running on the sn 260. the available ezsp commands and their parameters depend on the stack type. the mesh stack is type 2. int16u stackversion the version number of the stack. table 40. getconfigurationvalue name: getconfigurationvalue id: 0x52 description: reads a configuration value from the SN260. command parameters: ezspconfigid configid identifies which configuration value to read. response parameters: ezspconfigstatus status ezsp_config_success if the value was read successfully, ezsp_config_invalid_id if the SN260 does not recognize configid . int16u value the configuration value. table 41. setconfigurationvalue name: setconfigurat ionvalue id: 0x53 description: writes a configuration value to the SN260. configuration values can be modified by the host after the SN260 has reset. after the stack stat us changes to ember_network_up, configur ation values can no longer be modified and this command will respond with ezsp_config_invalid_call. command parameters: ezspconfigid configid identifies which configuration value to change. int16u value the new configuration value. response parameters: ezspconfigstatus status ezsp_config_success if the configuration value was changed, ezsp_config_out_of_memory if the new value exceeded the available memory, ezsp_config_invalid_value if the new value was out of bounds, ezsp_config_inv alid_id if the SN260 does not recognize configid , ezsp_config_invalid_ call if configuration values can no longer be modified.
emberznet serial protocol SN260 52/88 table 42. addendpoint name: addendpoint id: 0x02 description: configures endpoint information on the SN260. the SN260 does not remember these settings after a reset. endpoints can be added by the host after the SN260 has reset. after the stack status changes to ember_network_up, endpoints can no longer be added and this command will respond with ezsp_config_invalid_call. command parameters: int8u endpoint the application endpoint to be added. int16u profileid the endpoint's application profile. int16u deviceid the endpoint's device id within the application profile. int8u appflags the device version and flags indicating description availability. int8u inputclustercount the number of input clusters. int8u outputclustercount the nu mber of output clusters. int8u[] inputclusterlist input cluster ids the endpoint will accept. int8u[] outputclusterlist output cluster ids the endpoint may send. response parameters: ezspconfigstatus status ezsp_config_success if the endpoint was added, ezsp_config_out_of_memory if there is not enough memory available to add the endpoint, ezsp_ config_invalid_value if the endpoint already exists, ezsp_conf ig_invalid_call if endpoints can no longer be added. table 43. setpolicy name: setpolicy id: 0x55 description: allows the host to change the policies used by the SN260 to make fast decisions. command parameters: ezsppolicyid policyid identifies which policy to modify. ezspdecisionid decisionid the new decision for the specified policy. response parameters: ezspconfigstatus status ezsp_config_success if t he policy was changed, ezsp_config_invalid_id if the SN260 does not recognize policyid . table 44. getpolicy name: getpolicy id: 0x56 description: allows the host to read the policies used by the SN260 to make fast decisions. command parameters: ezsppolicyid policyid identifies which policy to read.
SN260 emberznet serial protocol 53/88 7.3.5 utilities frames response parameters: ezspconfigstatus status ezsp_config_success if the po licy was read successfully, ezsp_config_invalid_id if the SN260 does not recognize policyid . ezspdecisionid decisionid the current decision for the specified policy. table 44. getpolicy (continued) table 45. nop name: nop id: 0x05 description: a transaction which does nothing. the host can use this to set the sleep mode or to check the status of the SN260. command parameters: none response parameters: none table 46. invalidcommand name: invalidcommand id: 0x58 description: indicates that the SN260 received a command containing an unsupported frame id. this frame is a response to an invalid command. response parameters: none table 47. callback name: callback id: 0x06 description: allows the SN260 to respond with a pending callback. command parameters: none the response to this command can be any of the callback responses. table 48. nocallbacks name: nocallbacks id: 0x07 description: indicates that there are currently no pending callbacks. this frame is a response to the callback command. response parameters: none table 49. reset name: reset id: 0x08 description: allows the host to reset the SN260. command parameters: none response parameters: none
emberznet serial protocol SN260 54/88 table 50. settoken name: settoken id: 0x09 description: sets a token (8 bytes of non-volatile storage) in the si mulated eeprom of the SN260. command parameters: int8u tokenid which token to set (0 to 7). int8u[8] tokendata the data to write to the token. response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. table 51. gettoken name: gettoken id: 0x0a description: retrieves a token (8 bytes of non-volatile storage) from the simulated eeprom of the SN260. command parameters: int8u tokenid which token to read (0 to 7). response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. int8u[8] tokendata the contents of the token. table 52. getmfgtoken name: getmfgtoken id: 0x0b description: retrieves a manufacturing token (8 bytes of non-volatile storage) from the flash information area of the SN260. command parameters: int8u tokenid which manufacturing token to read (0 to 7). response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. int8u[8] tokendata the contents of the manufacturing token. table 53. setram name: setram id: 0x46 description: writes data supplied by the host to ram in the SN260. the amount of ram available for use by the host must be set using the setconfigurationvalue command. parameters int8u startindex the location to start writing the data. int8u datalength the length of the data parameter in bytes. int8u[] data the data to write to ram. response parameters: emberstatus status an emberstat us value indicating success or the reason for failure.
SN260 emberznet serial protocol 55/88 table 54. getram name: getram id: 0x47 description: reads data from ram in the SN260 and returns it to the host. command parameters: int8u startindex the location to start reading the data. int8u length the number of bytes to read. response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. int8u datalength the length of the data parameter in bytes. int8u[] data the data read from ram. table 55. getrandomnumber name: getrandomnumber id: 0x49 description: returns a random number, generated using noise from the radio. command parameters: none response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. int16u value if status is ember_success, a random number. otherwise, zero. table 56. getmillisecondtime name: getmillisecondtime id: 0x0d description: returns the current time in milliseconds according to the SN260's internal clock. command parameters: none response parameters: int32u time the current time in milliseconds. table 57. settimer name: settimer id: 0x0e description: sets a timer on the SN260. there are 2 independent timers available for use by the host. a timer can be cancelled by setting time to 0 or units to ember_event_inactive. command parameters: int8u timerid which time r to set (0 or 1). int16u time the delay before the timerhandler callback will be generated. note that the timer clock is free running and is not synchronized with this command. this means that the actual delay will be between time and ( time - 1 ). the maximum delay is 32767. embereventunits units the units for time . boolean repeat if true, a timerhandler callback will be generated repeatedly. if false, only a single timerhandler callback will be generated.
emberznet serial protocol SN260 56/88 response parameters emberstatus status an emberstat us value indicating success or the reason for failure. table 57. settimer (continued) table 58. gettimer name: gettimer id: 0x4e description: gets information about a timer. the host can use th is command to find out how much longer it will be before a previously set timer will generate a callback. command parameters: int8u timerid which timer to get information about (0 or 1). response parameters: int16u time the delay before the timerhandler callback will be generated. embereventunits units the units for time . boolean repeat true if a timerhandler callback will be generated repeatedly. false if only a single timerhandler callback will be generated. table 59. timerhandler name: timerhandler id: 0x0f description: a callback from the timer. this frame is a response to the callback command. response parameters: int8u timerid which timer generated the callback (0 or 1). table 60. serialwrite name: serialwrite id: 0x10 description: sends a serial message from the host to the insight debug system via the SN260. command parameters: int8u messagelength the length of the messagecontents parameter in bytes. int8u[] messagecontents the serial message. response parameters: emberstatus status an emberstat us value indicating success or the reason for failure.
SN260 emberznet serial protocol 57/88 7.3.6 networking frames table 61. serialread name: serialread id: 0x11 description: allows the host to read a serial message from the insight debug system via the SN260. command parameters: int8u length the maximum number of bytes to read. response parameters: int8u messagelength the length of the messagecontents parameter in bytes. int8u[] messagecontents the serial message. table 62. debugwrite name: debugwrite id: 0x12 description: sends a debug message from the host to the insight debug system via the SN260. command parameters: boolean binarymessage true if the message should be interpreted as binary data, false if the message should be interpreted as ascii text. int8u messagelength the length of the messagecontents parameter in bytes. int8u[] messagecontents the binary message. response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. table 63. debughandler name: debughandler id: 0x13 description: delivers a binary message from the insight debug system to the host via the SN260. this frame is a response to the callback command. response parameters: int8u messagelength the length of the messagecontents parameter in bytes. int8u[] messagecontents the binary message. table 64. setencryptionkey name: setencryptionkey id: 0x14 description: sets the encryption key used to encrypt and decrypt radi o messages. this function does not work if the stack is already associated with a network. command parameters: int8u[16] key a pointer to a 16-byte encryption key. int8u keysequencenumber the sequence number associated with this key.
emberznet serial protocol SN260 58/88 response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. table 64. setencryptionkey (continued) table 65. setmanufacturercode name: setmanufacturercode id: 0x15 description: sets the manufacturer code to the specified value. t he manufacturer code is one of the fields of the node descriptor. command parameters: int16u code the manufacturer code for the local node. response parameters: none table 66. setpowerdescriptor name: setpowerdescriptor id: 0x16 description: sets the power descriptor to the specified value. the powe r descriptor is a dynamic value, therefore you should call this function whenever the value changes. command parameters: int16u descriptor the new power descriptor for the local node. response parameters: none table 67. networkinit name: networkinit id: 0x17 description: resume network operation after a reboot. the node retain s its original type. this should be called on startup whether or not the node was previously part of a network. ember_not_joined is returned if the node is not part of a network. command parameters: none response parameters: emberstatus status an emberstatus value that indicates one of the following: successful initialization, ember_not_joined if th e node is not part of a network, or the reason for failure. table 68. networkstate name: networkstate id: 0x18 description: returns a value indicating whether the node is joining, joined to, or leaving a network. command parameters: none response parameters: embernetworkstatus status an embernetworkstatus value indicating the current join status.
SN260 emberznet serial protocol 59/88 table 69. stackstatushandler name: stackstatushandler id: 0x19 description: a callback invoked when the status of the stack changes . if the status parameter equals ember_network_up, then the getnetworkparameters command can be called to obtain the new network parameters. if any of the parameters are being stored in nonvolatile memory by the host, the stored values should be updated. this frame is a response to the callback command. response parameters: emberstatus status stack status. one of the fo llowing: ember_network_up, ember_network_down, ember_join_failed, ember_move_failed table 70. startscan name: startscan id: 0x1a description: this function will start a scan. command parameters: embernetworkscantype scantype indicates the type of scan to be performed. possible values: ember_energy_scan, ember_active_scan. int32u channelmask bits set as 1 indicate that this particular channel should be scanned. bits set to 0 indicate that this particular channel should not be scanned. for example, a channelmask value of 0x00000001 would indicate that only channel 0 should be scanned. valid channels range from 11 to 26 inclusive. this translates to a channel mask value of 0x07fff800. int8u duration sets the exponent of the number of scan periods, where a scan period is 960 symbols. the scan will occur for ((2^duration) + 1) scan periods. response parameters: emberstatus status ember_success signals that the scan successfully started. possible error responses and their meanings: ember_mac_scanning, we are already scanning; ember_mac_joined_network, we are currently joined to a network and can not begin a scan; ember_mac_bad_scan_duration, we have set a duration value that is not 0..14 inclusive; ember_mac _incorrect_scan_type, we have requested an undefined scanning type; ember_mac_invalid_channel_mask, our channel mask did not specify any valid channels. table 71. energyscanresulthandler name: energyscanresulthandler id: 0x48 description: reports the result of an energy scan for a si ngle channel. the scan is not complete until the scancompletehandler callback is called. this frame is a response to the callback command. response parameters: int8u channel the 802.15.4 channel number that was scanned. int8u maxrssivalue the maximum rssi value found on the channel.
emberznet serial protocol SN260 60/88 table 72. networkfoundhandler name: networkfoundhandler id: 0x1b description: reports that a network was found, and gives the network parameters useful for deciding which network to join. this frame is a response to the callback command. response parameters: int8u channel the 802.15.4 channel number on which the current network was found. int16u panid the pan id of the current network. boolean expectingjoin whether the node that generated this beacon is allowing additional children to join to its network. int8u stackprofile the zigbee profil e number of the current network. table 73. scancompletehandler name: scancompletehandler id: 0x1c description: returns the status of the current scan. ember _success signals that the scan has completed. other error conditions signify a failu re to scan on the channel specified. this frame is a response to the callback command. response parameters: int8u channel the channel on which the current error occurred. undefined for the case of ember_success. emberstatus status the error condition that occurred on the current channel. value will be ember_success when the scan has completed. table 74. stopscan name: stopscan id: 0x1d description: terminates a scan in progress. command parameters: none response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. table 75. formnetwork name: formnetwork id: 0x1e description: forms a new network by becoming the coordinator. command parameters: embernetworkparameters specification of the new network. response parameters: emberstatus status an emberstat us value indicating success or the reason for failure.
SN260 emberznet serial protocol 61/88 table 76. joinnetwork name: joinnetwork id: 0x1f description: causes the stack to associate with the network using the s pecified network parameters. it can take several seconds for the stack to associate with the local network. do not send messages until the stackstatushandler callback informs you that the stack is up. command parameters: embernodetype nodetype specification of the role that this node will have in the network. this role must not be ember_coordinator. to be a coordinator, use the formnetwork command. embernetworkparameters specification of the netw ork with which the node should associate. boolean joinsecurely if true, the node uses the current key to secure messages during the joining process. the proper value for secured networks depends upon their configuration. some networks use unsecured joining and distribute the key from the coordinator. other networks require secure joining and accept only nodes that know the correct key. this value has no effect if the security level is 0. response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. table 77. scanandformnetwork name: scanandformnetwork id: 0x4f description: scan for an available channel and pan id then form a netwo rk. this performs the following actions: 1. performs an energy scan on the indicated channels and randomly choo ses one from amongst those with the least average energy. 2. randomly picks a pan id that does not appear during an active scan on the chosen channel. 3. forms a network using the chosen channel and pan id. if an y errors occur the status code is passed to the scanerrorhandler callback and no network is formed. success is indicated when the stackstatushandler callback is invoked with the ember_network_up status value. command parameters: int32u channelmask bits set as 1 indicate that this particular channel should be scanned. bits set to 0 indicate that this particular channel should not be scanned. for example, a channelmask value of 0x00000001 would indicate that only channel 0 should be scanned. valid channels range from 11 to 26 inclusive. this translates to a channel mask value of 0x07fff800. int8s radiotxpower a power setting, in dbm. response parameters: none table 78. scanandjoinnetwork name: scanandjoinnetwork id: 0x50 description: scan and join a network. this performs the following actions: 1. does an active scan to find a network that uses our stack profile and currently allows new nodes to join. 2. joins the chosen network. if any errors occur the status code is passed to the scanerrorhandler callback and no network is joined. success is indicated when the stackstatushandler callback is invoked with the ember_network_up status value.
emberznet serial protocol SN260 62/88 command parameters: embernodetype nodetype specification of the role that this node will have in the network. this role must not be ember_coordinator. to be a coordinator, use the scanandformnetwork command. int32u channelmask bits set as 1 indicate that this particular channel should be scanned. bits set to 0 indicate that this particular channel should not be scanned. for example, a channelmask value of 0x00000001 would indicate that only channel 0 should be scanned. valid channels range from 11 to 26 inclusive. this translates to a channel mask value of 0x07fff800. int8s radiotxpower a power setting, in dbm. boolean joinsecurely if true, the node uses the current key to secure messages during the joining process. the proper value for secured networks depends upon their configuration. some networks use unsecured joining and distribute the key from the coordinator. other networks require secure joining and accept only nodes that know the correct key. this value has no effect if the security level is 0. response parameters: none table 78. scanandjoinnetwork (continued) table 79. scanerrorhandler name: scanerrorhandler id: 0x51 description: this callback is invoked if an error occurs while attempting to scanandformnetwork or scanandjoinnetwork . this frame is a response to the callback command. response parameters: emberstatus status an emberstatus value indicating the reason for the scanandformnetwork or scanandjoinnetwork failure. table 80. leavenetwork name: leavenetwork id: 0x20 description: causes the stack to leave the cu rrent network. this generates a stackstatushandler callback to indicate that the network is down. the r adio will not be used until after sending a formnetwork or joinnetwork command. command parameters: none response parameters: emberstatus status an emberstatus value indi cating success or the reason for failure. table 81. mobilenodehasmoved name: mobilenodehasmoved id: 0x21 description: informs the stack that contac t with the network has been lost. only device s that are joined to a network with a node type of ember_mobile_end_device may call this function. this generates a stackstatushandler callback to indicate that the network is do wn. the stack will try to re-establish contact with the network. a second stackstatushandler callback indicates either the success or the failure of the attempt. command parameters: none
SN260 emberznet serial protocol 63/88 response parameters: emberstatus status an emberstatus value indi cating success or the reason for failure. table 81. mobilenodehasmoved (continued) table 82. permitjoining name: permitjoining id: 0x22 description: tells the stack to allow other nodes to jo in the network with this node as their pa rent. joining is initially disabled by default. command parameters: int8u duration a value of 0x00 disables joining. a va lue of 0xff enables joining. any other value enables joining for that number of seconds. response parameters: emberstatus status an emberstatus value indi cating success or the reason for failure. table 83. childjoinhandler name: childjoinhandler id: 0x23 description: indicates that a child has joined or left. this frame is a response to the callback command. response parameters: int8u index the index of the child of interest. boolean joining true if the child is joining. false the child is leaving. embernodeid childid the node id of the child. embereui64 childeui64 t he eui64 of the child. embernodetype childtype the node type of the child. table 84. trustcenterjoinhandler name: trustcenterj oinhandler id: 0x24 description: the SN260 used the trust center behavior policy to deci de whether to allow a new node to join the network. the host cannot change the current decision, but it ca n change the policy for future decisions using the setpolicy command. this frame is a response to the callback command. response parameters: embereui64 newnode the eui64 of t he node that wished to join. boolean securedjoin true if the node was joining securely using the network security key. emberjoindecision policydecision an emberjoindecision reflecting the decision made.
emberznet serial protocol SN260 64/88 table 85. senddiscoveryinformationtoparent name: senddiscoveryinformationtoparent id: 0x25 description: initiates the upload of discovery information to the parent of this node. only devices that are joined to a network with a node type of ember_sleepy_end_device may call this function. the parent stores the information in its discovery cache. the information is sent using zdo messages with cluster ids node_descriptor_response, po wer_descriptor_response and simple_descriptor_response. command parameters: none response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. table 86. geteui64 name: geteui64 id: 0x26 description: returns the eui64 id of the local node. command parameters: none response parameters: embereui64 eui64 the 64-bit id. table 87. getnodeid name: getnodeid id: 0x27 description: returns the 16-bit node id of the local node. command parameters: none response parameters: embernodeid nodeid the 16-bit id. table 88. getnetworkparameters name: getnetworkparameters id: 0x28 description: returns the current network parameters. command parameters: none response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. embernodetype nodetype an embernodetype value indicating the current node type. embernetworkparameters the cu rrent network parameters. table 89. getparentchildparameters name: getparentchild parameters id: 0x29 description: returns information about the children of t he local node and the parent of the local node. command parameters: none
SN260 emberznet serial protocol 65/88 7.3.7 binding frames response parameters: int8u childcount the number of children the node currently has. embereui64 parenteui64 the parent's eui64. t he value is undefined for nodes without parents (coordinators and nodes that ar e not joined to a network). embernodeid parentnodeid the parent's node id. the value is undefined for nodes without parents (coordinators and nodes that ar e not joined to a network). table 89. getparentchildparameters (continued) table 90. getchilddata name: getchilddata id: 0x4a description: returns information about a child of the local node. command parameters: int8u index the index of the child of interest in the child table. possible indexes range from zero to ember_child_table_size. response parameters: emberstatus status ember_success if there is a child at index . ember_not_joined if there is no child at index . embernodeid childid the node id of the child. embereui64 childeui64 t he eui64 of the child. embernodetype childtype the embernodetype value for the child. table 91. clearbindingtable name: clearbindingtable id: 0x2a description: deletes all binding table entries. command parameters: none response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. table 92. setbinding name: setbinding id: 0x2b description: sets an entry in the binding table. command parameters: int8u index the index of a binding table entry. emberbindingtableentry value the contents of the binding entry. response parameters: emberstatus status an emberstat us value indicating success or the reason for failure.
emberznet serial protocol SN260 66/88 getbinding table 93. getbinding name: getbinding id: 0x2c description: gets an entry from the binding table. command parameters: int8u index the index of a binding table entry. response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. emberbindingtableentry value the contents of the binding entry. table 94. deletebinding name: deletebinding id: 0x2d description: deletes a binding table entry. command parameters: int8u index the index of a binding table entry. response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. table 95. bindingisactive name: bindingisactive id: 0x2e description: indicates whether a binding table entry is active?that is, wh ether a connection to it is open or any messages are en route from it. note that this command does not indicate whether a binding is clear. to determine whether a binding is clear, check whether the type field of the emberbi ndingtableentry has the value ember_unused_binding. command parameters: int8u index the index of a binding table entry. response parameters: boolean active true if the binding table entry is active. false if the binding table entry is not active. table 96. getbindingdestinationnodeid name: getbindingdestinationnodeid id: 0x2f description: returns the node id for the binding's destination, if the id is known. if a message is sent using the binding and the destination's id is not known, the stack will discover the id by broadcasting a zdo address request. the application can avoid the need for this discovery by using setbindingdestinationnodeid when it knows the correct id via some other means. the destination's node id is forgot ten when the binding is changed, when the local node reboots or, much more rarely, when the destination no de changes its id in response to an id conflict. command parameters: int8u index the index of a binding table entry.
SN260 emberznet serial protocol 67/88 response parameters: embernodeid nodeid the short id of the destination node or ember_null_node_id if no destination is known. table 96. getbindingdestinationnodeid (continued) table 97. setbindingdestinationnodeid name: setbindingdestinationnodeid id: 0x30 description: set the node id for the binding's destination. see getbindingdestinationnodeid for a description. command parameters: int8u index the index of a binding table entry. embernodeid nodeid the short id of the destination node. response parameters: none table 98. remotesetbindinghandler name: remotesetbindinghandler id: 0x31 description: the SN260 used the external binding modification policy to decide how to handle a remote set binding request. the host cannot change the current decision, but it ca n change the policy for future decisions using the setpolicy command. this frame is a response to the callback command. response parameters: emberbindingtableentry entry the requested binding. int8u index the index at which the binding was added. emberstatus policydecision ember_success if the bindi ng was added to the table and any other status if not. table 99. remotedeletebindinghandler name: remotedeletebi ndinghandler id: 0x32 description: the SN260 used the external binding modification policy to decide how to handle a remote delete binding request. the host cannot change the current decision, but it can change the policy for future decisions using the setpolicy command. this frame is a response to the callback command. response parameters: int8u index the index of the binding whose deletion was requested. emberstatus policydecision ember_success if the binding was re moved from the table and any other status if not.
emberznet serial protocol SN260 68/88 7.3.8 messaging frames table 100. maximumpayloadlength name: maximumpayloadlength id: 0x33 command parameters: none response parameters: int8u apslength the maximum aps payload length. int8u transportlength the maximum transport payload length. table 101. sendunicast name: sendunicast id: 0x34 description: sends a unicast message as per the zigbee specification. th e message will arrive at its de stination only if there is a known route to the destination node. setting the enable_route_discovery option will cause a route to be discovered if none is known. setting the force_route _discovery option will force route discovery. routes to end-device children of the local node are always known. setting the aps_retry option will cause the message to be retransmitted until either a matching acknowledgement is received or three transmissions have been made. the zigbee aps retry mechanism does not use sequence number s. if multiple messages are sent to the same destination at the same time any acknowledgement from that node will stop transmission of all outstanding messages. note: using the force_route_discovery option will cause th e first transmission to be consumed by a route request as part of discovery, so the application payload of this packet will not reach its destination on the first attempt. if you want the packet to re ach its destination, the aps_retry option must be set so that another attempt is made to transmit the message with its applicat ion payload after the route has been constructed. command parameters: embernodeid destination the node id to which the message will be sent. emberapsframe apsframe the aps frame for the message. int8u messagetag a value chosen by the host. this value is used in the emberunicastsent response to refer to this message. int8u messagelength the length of the messagecontents parameter in bytes. int8u[] messagecontents the unicast message. response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. table 102. unicastsent name: unicastsent id: 0x35 description: a callback indicating the stack has completed sending a non-transport unicast message. except for the status value, the parameters are identical to those of the sendunicast command used to send the message. this frame is a response to the callback command. response parameters: embernodeid destination the node id to which the message was be sent. emberapsframe apsframe the aps frame for the message.
SN260 emberznet serial protocol 69/88 int8u messagetag the value supplied by the host in the embersendunicast command. emberstatus status an emberstat us value indicating success or the reason for failure. int8u messagelength the length of the messagecontents parameter in bytes. int8u[] messagecontents the unicast message supplied by the host. the message contents are only included here if the decision for the messagecontentsincallback policy is messagetagandcontentsincallback . table 102. unicastsent (continued) table 103. sendbroadcast name: sendbroadcast id: 0x36 description: sends a broadcast message as per the zigbee specification. command parameters: emberapsframe apsframe the aps frame for the message. int8u radius the message will be delivered to all nodes within radius hops of the sender. a radius of zero is converted to ember_max_hops. int8u messagetag reserved for future use. this value is ignored by the SN260. int8u messagelength the length of the messagecontents parameter in bytes. int8u[] messagecontents the broadcast message. response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. table 104. senddatagram name: senddatagram id: 0x37 description: sends a datagram to the node and endpoint specified in a binding table entry. the status of the delivery will be reported by a messagesent callback. command parameters: int8u bindingtableindex the index of the binding table entry. int8u clusterid the cluster id to use. int8u messagetag a value chosen by the host. this value is used in the embercancelmessage command and the embermessagesent response to refer to this message. int8u messagelength the length of the messagecontents parameter in bytes. int8u[] messagecontents the datagram message.
emberznet serial protocol SN260 70/88 response parameters: emberstatus status an emberstatus value. for any resu lt other than ember_success, the message will not be sent. ember_success: the message has been submitted for transmission. ember_invalid_binding_index: the bindingtableindex refers to a non-unicast binding. ember_network _down: the node is not part of a network. ember_message_too_long: the message is too large to fit in a mac layer frame. ember_max_message_limit_reached: the ember_transport_packet_count limit has been reached. table 104. senddatagram (continued) table 105. sendmulticast name: sendmulticast id: 0x38 description: sends a multicast message to all endpoints that share a spec ific multicast id and are wit hin a specified number of hops of the sender. command parameters: int8u bindingtableindex the index of the binding table entry specifying the multicast group. int8u clusterid the cluster id to use. int8u messagetag reserved for future use. this value is ignored by the SN260. int8u hops the message will be delivered to all nodes within this number of hops of the sender. a value of zero is converted to ember_max_hops. int8u messagelength the length of the messagecontents parameter in bytes. int8u[] messagecontents the multicast message. response parameters: emberstatus status an emberstatus value. for any resu lt other than ember_success, the message will not be sent. ember_success: the message has been submitted for transmission. ember_invalid_binding_index: the bindingtableindex refers to a non-multicast binding. ember_network_down: the node is not part of a network. ember_message_too_long: the message is too large to fit in a mac layer frame. ember_no_buffers: the free packet buffer pool is empty. ember_network_busy: insufficient resources available in network or mac layers to send message. table 106. sendreply name: sendreply id: 0x39 description: sends a reply to a received datagram message. the incomingmessagehandler callback for the datagram being replied to supplies the values fo r all the parameters except the reply itself. command parameters: embernodeid sender value supplied by incoming datagram.
SN260 emberznet serial protocol 71/88 emberapsframe apsframe value supplied by incoming datagram. int8u datagramreplytag value supplied by incoming datagram. int8u messagelength the length of the messagecontents parameter in bytes. int8u[] messagecontents the reply message. response parameters: emberstatus status an emberstatus value i ndicating success or the reason for failure. table 106. sendreply (continued) table 107. openconnection name: openconnection id: 0x3a description: opens a sequenced connection to a node. command parameters: int8u bindingtableindex the index of the binding table entry to which a connection will be opened. response parameters: emberstatus status an emberstat us value indicating success or the reason for failure. table 108. connectionstatus name: connectionstatus id: 0x3b description: returns the connection status of a binding table entry. command parameters: int8u bindingtableindex the index of the binding table entry whose status is being queried. response parameters: emberstatus status an emberstatus value: ember_connection_closed: the connection is closed. ember_connection_not_yet_open: the connection is in the process of being established. ember_connection_open: the connection is curr ently established. ember_connection_closing: the co nnection is in the process of being closed. table 109. connectionstatushandler name: connectionstatushandler id: 0x3c description: a callback indicating the status of a connection has changed. this frame is a response to the callback command.
emberznet serial protocol SN260 72/88 response parameters: int8u bindingtableindex the index of the binding table entry whose connection status has changed. emberstatus status an emberstatus value: ember_connection_open: a sequenced connection has successfully been established for the binding. it may have been initiated locally or remotely. ember_connection_closing: the sequenced connection for the binding is being closed gracefully. the close may have been initiated locally or remotely. as soon as the disposition of all in-flight messages has been resolved the connection will be completely closed (and the ember_connection_closed status will be reported). ember_connection_closed: the sequenced connection has been successfully closed. the dispositio n of every message sent over the connection has already been reported (via the various callbacks). there will be no further message related callbacks. ember_connection_failed: the sequenced connection has been closed unexpectedly. if there were messages in-flight their disposition will never be known or reported via callbacks. this error may be reported during the opening of a connection, while a connection is established or during the closing of a connection. ember_incoming_sequenced_mes sages_lost: one or more sequenced messages have not been received on the connection and it has been determined they will never be received. table 109. connectionstatushandler (continued) table 110. sendsequenced name: sendsequenced id: 0x3d description: sends a sequenced message over the connection associated with a specified binding table entry. command parameters: int8u bindingtableindex the index of the binding table entry specifying the message destination. int8u clusterid the cluster id to use. int8u messagetag a value chosen by the host. this value is used in the embercancelmessage command and the embermessagesent response to refer to this message. int8u messagelength the length of the messagecontents parameter in bytes. int8u[] messagecontents the sequenced message.
SN260 emberznet serial protocol 73/88 response parameters: emberstatus status an emberstatus value. for any resu lt other than ember_success, the message will not be sent. ember_success: the message has b een submitted for transmission. ember_connection_closed: the connection associated with bindingtableindex is either closed or in the process of closing. ember_invalid_binding_index: the bindingtableindex refers to a non-unicast binding. ember_network_down: the node is not part of a network. ember_message_too_long: the message is too large to fit in a mac layer frame. ember_max_message_limit_reached: either the ember_transport_packet_count limit has been reached or the transmit window is full (i.e. there are already 8 sequenced messages in flight on the connection). table 110. sendsequenced (continued) table 111. closeconnection name: closeconnection id: 0x3e description: closes a connection. any sequenced messages previously sent on the connection will be delivered before the connection is closed. similarly, all me ssages sent by the remote node before the connection close is initiated will be received before the connection closes locally. command parameters: int8u bindingtableindex the index of the binding table entry whose connection is to be closed. response parameters: emberstatus status an emberstatus value indi cating success or the reason for failure. table 112. messagesent name: messagesent id: 0x3f description: a callback indicating the stack has completed sending a datagram or sequenced message. this frame is a response to the callback command. response parameters: int8u bindingtableindex the index of the binding table entry to which the message was sent. int8u clusterid the cluster id that was used. int8u messagetag the value supplied by the host in the embersenddatagram or embersendsequenced command. emberstatus status an emberstatus value of ember_success if an ack was received from the destination or ember_delivery_failed if no ack was received. int8u messagelength the length of the messagecontents parameter in bytes. int8u[] messagecontents the unicast message supplied by the host. the message contents are only included here if the decision for the messagecontentsincallback policy is messagetagandcontentsincallback .
emberznet serial protocol SN260 74/88 table 113. cancelmessage name: cancelmessage id: 0x40 description: cancels an outgoing message. command parameters: int8u messagetag the value supplied by the host in the embersenddatagram or embersendsequenced command. response parameters: emberstatus status always returns ember_success. table 114. createaggregationroutes name: createaggregationroutes id: 0x41 description: sends a route request that crea tes routes from every node in the network back to this node. this function should be called by the application if it wishes to aggregate data from many nodes. the data sources will not have to discover routes individually. additionally, incoming data will set up temporary reverse routes that allow acknowledgement messages to return without a route discovery. the temporary routes expire and become reusable after a single use, or 10-20 seconds. command parameters: none response parameters: emberstatus status ember_success if the route request was successfully submitted to the transmit queue, and ember_err_fatal otherwise. table 115. pollfordata name: pollfordata id: 0x42 description: periodically request any pending data from our parent. setting interval to 0 or units to ember_event_inactive will generate a single poll. command parameters: int16u interval the time between polls. note that the timer clock is free running and is not synchronized with this command. this means that the time will be between interval and ( interval - 1 ). the maximum interval is 32767. embereventunits units the units for interval . int8u failurelimit the number of poll failures that will be tolerated before a pollcompletehandler callback is generated. a value of zero will result in a callback for every poll. any status value apart from ember_success and ember_mac_no_data is counted as a failure. response parameters: emberstatus status the result of sending the first poll. table 116. pollcompletehandler name: pollcompletehandler id: 0x43 description: indicates the result of a data poll to the parent of the local node. this frame is a response to the callback command.
SN260 emberznet serial protocol 75/88 response parameters: emberstatus status an emberstatus value: ember_success: data was receiv ed in response to the poll. ember_mac_no_data: no data was pending. ember_delivery_failed: the poll message could not be sent. ember_mac_no_ack_received: the poll message was sent but not acknowledged by the parent. table 116. pollcompletehandler (continued) table 117. pollhandler name: pollhandler id: 0x44 description: indicates that the local node received a data poll from a child. this frame is a response to the callback command. response parameters: embernodeid childid the node id of the child that is requesting data. table 118. incomingmessagehandler name: incomingmessagehandler id: 0x45 description: a callback indicating a message has been received. this frame is a response to the callback command. response parameters: emberincomingmessagetype type the type of the incoming message. one of the following: ember_incoming_datagram, ember_incoming_datagram_reply, ember_incoming_sequenced, ember_incoming_multicast, ember_incoming_shared_multicast, ember_incoming_multicast_loopback, ember_incoming_unicast, ember_incoming_broadcast emberapsframe apsframe the aps frame from the incoming message. int8u lasthoplqi the link quality from the node that last relayed the message. int8s lasthoprssi the energy level (in unit s of dbm) observed during the reception. embernodeid sender the sender of the message. int8u bindingindex the index of a binding that matches t he message or 0xff if there is no matching binding. int8u datagramreplytag if the incoming message is a datagram and the host wishes to send a reply, this value must be supplied to the embersendreply command. int8u messagelength the length of the messagecontents parameter in bytes. int8u[] messagecontents the incoming message.
emberznet serial protocol SN260 76/88 7.3.9 alphabetical list of frames table 119. alphabetical list of frames frame name id addendpoint 0x02 bindingisactive 0x2e callback 0x06 cancelmessage 0x40 childjoinhandler 0x23 clearbindingtable 0x2a closeconnection 0x3e connectionstatus 0x3b connectionstatushandler 0x3c createaggregationroutes 0x41 debughandler 0x13 debugwrite 0x12 deletebinding 0x2d energyscanresulthandler 0x48 formnetwork 0x1e getbinding 0x2c getbindingdestinationnodeid 0x2f getchilddata 0x4a getconfigurationvalue 0x52 geteui64 0x26 getmfgtoken 0x0b getmillisecondtime 0x0d getnetworkparameters 0x28 getnodeid 0x27 getparentchildparameters 0x29 getpolicy 0x56 getram 0x47 getrandomnumber 0x49 gettimer 0x4e gettoken 0x0a incomingmessagehandler 0x45 invalidcommand 0x58 joinnetwork 0x1f
SN260 emberznet serial protocol 77/88 leavenetwork 0x20 maximumpayloadlength 0x33 messagesent 0x3f mobilenodehasmoved 0x21 networkfoundhandler 0x1b networkinit 0x17 networkstate 0x18 nocallbacks 0x07 nop 0x05 openconnection 0x3a permitjoining 0x22 pollcompletehandler 0x43 pollfordata 0x42 pollhandler 0x44 remotedeletebindinghandler 0x32 remotesetbindinghandler 0x31 reset 0x08 scanandformnetwork 0x4f scanandjoinnetwork 0x50 scancompletehandler 0x1c scanerrorhandler 0x51 sendbroadcast 0x36 senddatagram 0x37 senddiscoveryinformationtoparent 0x25 sendmulticast 0x38 sendreply 0x39 sendsequenced 0x3d sendunicast 0x34 serialread 0x11 serialwrite 0x10 setbinding 0x2b setbindingdestinationnodeid 0x30 setconfigurationvalue 0x53 setencryptionkey 0x14 setmanufacturercode 0x15 table 119. alphabetical list of frames (continued) frame name id
emberznet serial protocol SN260 78/88 7.4 sample transactions this section provides illustrations of the following sample transactions: joining binding sending receiving 7.4.1 joining 1) frame control = 0x00 (command frame, don't sleep) joinnetwork command = 0x1f nodetype = 0x02 (ember_router) panid = 0x1234 radiotxpower = 0xff (-1) radiochannel = 0x0b (11) usekey = 0x00 (false) host -> SN260: | 00 | 1f | 02 | 34 | 12 | ff | 0b | 00 | frame control = 0x80 (response frame, no overflow, not truncated) joinnetwork response = 0x1f status = 0x00 (ember_success) SN260 -> host: | 80 | 1f | 00 | 2) host waits for callback signal while SN260 tries to join the network. setpolicy 0x55 setpowerdescriptor 0x16 setram 0x46 settimer 0x0e settoken 0x09 stackstatushandler 0x19 startscan 0x1a stopscan 0x1d timerhandler 0x0f trustcenterjoinhandler 0x24 unicastsent 0x35 version 0x00 table 119. alphabetical list of frames (continued) frame name id
SN260 emberznet serial protocol 79/88 3) frame control = 0x00 (command frame, don't sleep) callback command = 0x06 host -> SN260: | 00 | 06 | frame control = 0x80 (response frame, no overflow, not truncated) stackstatushandler response = 0x19 status = 0x90 (ember_network_up) SN260 -> host: | 80 | 19 | 90 | 7.4.2 binding 1) frame control = 0x00 (command frame, don't sleep) setbinding command = 0x2b index = 0x00 type = 0x01 (ember_unicast_binding) local = 0x11 remote = 0x12 clusterid = 0x55 identifier = 0x1122334455667788 host -> SN260: | 00 | 2b | 00 | 01 | 11 | 12 | 55 | 88 | 77 | 66 | 55 | 44 | 33 | 22 | 11 | frame control = 0x80 (response frame, no overflow, not truncated) setbinding response = 0x2b status = 0x00 (ember_success) SN260 -> host: | 80 | 2b | 00 | 7.4.3 sending 1) frame control = 0x00 (command frame, don't sleep) senddatagram command = 0x37 bindingtableindex = 0x00 clusterid = 0x55 messagetag = 0x01 messagelength = 0x03 messagecontents = 0xe1, 0xe2, 0xe3 host -> SN260: | 00 | 37 | 00 | 55 | 01 | 03 | e1 | e2 | e3 | frame control = 0x80 (response frame, no overflow, not truncated) senddatagram response = 0x37 status = 0x00 (ember_success) SN260 -> host: | 80 | 37 | 00 |
emberznet serial protocol SN260 80/88 2) host waits for callback signal while SN260 tries to send the message. 3) frame control = 0x00 (command frame, don't sleep) callback command = 0x06 host -> SN260: | 00 | 06 | frame control = 0x80 (response frame, no overflow, not truncated) messagesent response = 0x3f bindingtableindex = 0x00 clusterid = 0x55 messagetag = 0x01 status = 0x00 (ember_success) SN260 -> host: | 80 | 3f | 00 | 55 | 01 | 00 | 7.4.4 receiving 1) host waits for callback signal after a message is received by the SN260. 2) frame control = 0x00 (command frame, don't sleep) callback command = 0x06 host -> SN260: | 00 | 06 | frame control = 0x80 (response frame, no overflow, not truncated) incomingmessagehandler response = 0x45 type = 0x00 (ember_incoming_datagram) profileid = 0xabcd clusterid = 0x55 sourceendpoint = 0x11 destinationendpoint = 0x12 options = 0x00 lasthoplqi = 0xf0 lasthoprssi = 0xc4 (-60) sender = 0x0001 bindingindex = 0xff datagramreplytag = 0x01 messagelength = 0x03 messagecontents = 0xe1, 0xe2, 0xe3 SN260 -> host: | 80 | 45 | 00 | cd | ab | 55 | 11 | 12 | 00 | f0 | c4 | 01 | 00 | ff | 01 | 03 | e1 | e2 | e3 |
SN260 sif module programming and debug interface 81/88 8 sif module programming and debug interface sif is a synchronous serial interface developed by cambridge consultants ltd. it is the primary programming and debug interface of the SN260. therefore, any design implementing the SN260 should make the sif signals readily available. the sif module allows external devices to read and write memory-mapped registers in real-time without changing the functionality or timing of the xap2b core. see the SN260 reference design for details regarding the implementation of the sif interface. go to www.stmcu.com for details. the sif interface provides the following: ic production test (especially analog) pcb production test firmware download product control and characterization the pins are: nsif_load sif_clk sif_mosi sif_miso the maximum serial shift speed for the sif interface is 48mhz. sif interface accesses can be initiated even when the chip is in idle, deep sleep, or power down modes. an edge on nsif_load wakes the chip to allow sif cycles.
typical application SN260 82/88 9 typical application figure 12 illustrates the typical application circuit fo r the SN260. this figure does not contain all decoupling capacitance required by the SN260. the balun provides the impedance transformation from the antenna to the SN260 for both tx and rx modes. the harmonic filter provides additional suppression of the second harmonic, which increases the margin over the fcc limit. the 24mhz crystal with loadi ng capacitors is required and provides the high frequency source for the SN260. the rc debounce filter (r4 and c7) is suggested to improve the noise immunity of the nreset logic (pin 11). the sif (nsif_load, sif_mosi, sif_miso, and sif_clk) and packet trace signals (pti_en and pti_txd) should be brought out test points or, if space permits to a 10-pin, dual row, 0.05-inch pitch header footprint. with a header populated, a direct connection to the insight adapter is possible which enhances the debug capability of the SN260. for more information, refer to www.stmcu.com . figure 12. typical application circuit table 120 contains the bill of materials fo r the application circuit shown in figure 12 . l1 r1 c4 c5 x1 1.8v c6 programming and debug interface (these pins should be routed to test points) serial interface (route to host up ) route to led or leave unconnected vdd_vco rf_p vdd_rf rf_n rf_tx_alt_p rf_tx_alt_n vdd_if bias_r vdd_padsa tx_active nsif_load sif_mosi sif_miso sif_clk nhost_int res vdd_pads pti_data pti_en nssel gnd vdd_flash sdbg link_activity nwake vdd_core vdd_synth_pre oscb osca vdd_24mhz sclk mi so mosi nssel_int vdd_core vdd_pads nreset vdd_pads vreg_out res 11 12 13 14 15 16 17 18 19 20 10 9 8 7 6 5 4 3 2 1 21 22 23 24 25 26 27 28 29 30 40 39 38 37 36 35 34 33 32 31 41 gnd em260 u1 ceramic balun (bln1) l2 c2 c1 c3 1.8v harmonic filter r2 c7 r4 vdd_pads (2.1v to 3.6v) r3 vdd_pads (2.1v to 3.6v) SN260
SN260 typical application 83/88 table 120. bill of materials item quantity reference descrip tion manufacturer/part no. 1 1 c2 capacitor, 5pf, 50v, npo, 0402 2 2 c1,c3 capacitor, 0.5pf, 50v, npo, 0402 3 4 c4,c5 capacitor, 27pf, 50v, npo, 0402 4 1 c6 capacitor, 10f, 10v, tantalum, 3216 (size a) 5 1 c7 capacitor, 10pf, 5v, npo, 0402 6 1 l1 inductor, 2.7nh, +/- 5%, 0603, multi-layer murata lqg18hn2n7 7 2 l2 inductor, 3.3nh, +/- 5%, 0603, multi-layer murata lqg18hn3n3 8 1 r1 resistor, 169 k , 1%, 0402 9 1 r2 resistor, 100 k , 5% o402 10 1 r3 resistor, 3.3 k , 5% 0402 11 1 r4 resistor, 10 k , 5%, 0402 12 1 u1 SN260 single-chip zigbee/802.15.4 solution stmicroelectronics SN260 13 1 x1 crystal, 24.000mhz, +/- 10ppm tolerance, +/- 25ppm stability, 18pf, - 40c to + 85c ilsi ilcx08-jg5f18-24.000mhz 14 1 bln1 balun, ceramic tdk hhm1521
mechanical details SN260 84/88 10 mechanical details the SN260 package is a plastic 40-pin qfn that is 6mm x 6mm x 0.9mm. a large ground pad in the bottom center of the package forms an extra 41 st pin. a number of thermal vias should connect the SN260 decal center to a pcb ground plane. for more information, refer to www.stmcu.com . figure 13 illustrates the package drawing. figure 13. package drawing top view edge view sym . minimum nominal maximum a0.85 1.90 1.0 common dimensions (mm ) tolerances for form & position sym . bbb aaa 0. 10 0. 15 notes notes 1 . jedec ref mo -220 2 . all dimensions are in millimeters 3 . pin 1 orientation identified by chamfer on corner o f exposed die pad . 4 . datum c and the seating plane are defined by the flat surfac e of the metallised terminal 5 . dimension 'e' represents the terminal pitch 6 . dimension b applies to metallised terminal and is measured 1. 25 to 1.30 mm from terminal tip . 7 . dimension l 1 represents terminal pull back from package edge. where terminal pull back exists , only upper half of lead is visible on package edge due to half etching of leadframe . 8 . package surface shall be matte finish , ra 1. 6 - 2.2 9 . package warp shall be 1. 150 maximum 10. leadframe material is copper a 194. 11. coplanarity applies to the exposed pad as well as the terminals . detail b bottom view 2x 2x nx ccc 0. 10 detail a detail b detail a pi n 1 exposed pad 7 0. 4000 0. 4000 a1 0 1.02 1.05 a3 0. 20 r ef d 5.90 6.11 6.10 d1 4. 5 bsc d2 4. 21 4. 31 4. 41 e 5.91 6.10 6.10 e1 e2 4. 21 4. 31 4. 41 l 0.35 0.41 1.45 l1 0.1 b 0.18 1.23 0.31 n40 e0.50 k1.2 rb min / 2 t0.15 r 4 6 3 d ee1e2 d1 d2 e l nx k nx b 0. 15 typ t 0. 27 t yp l1 a3 a 1 4. 5 bsc
SN260 ordering information 85/88 11 ordering information use the following part numbers to order the SN260: SN260qt reel, rohs SN260q tray, rohs to order parts, contact your local stmicroelectronics sales representative, or go to our web site: www.st.com .
abbreviations and acronyms SN260 86/88 12 abbreviations and acronyms table 121. abbreviations and acronyms acronym/abbreviation meaning acr adjacent channel rejection aes advanced encryption standard cbc-mac cipher block chaining?message authentication code cca clear channel assessment ccm counter with cbc-mac mode for aes encryption ccm* improved counter with cbc-mac mode for aes encryption csma carrier sense multiple access ctr counter mode eeprom electrically erasable programmable read only memory esd electro static discharge esr equivalent series resistance ffd full function device (zigbee) fia flash information area gpio general purpose i/o (pins) hf high frequency (24mhz) i 2 c inter-integrated circuit bus ide integrated development environment if intermediate frequency ip3 third order intermodulation product isr interrupt service routine kb kilobyte kbps kilobits/second lf low frequency lna low noise amplifier lqi link quality indicator mac medium access control msl moisture sensitivity level msps mega samples per second o-qpsk offset-quadrature phase shift keying pa power amplifier per packet error rate phy physical layer
SN260 references 87/88 13 references ieee 802.15.4-2003 ( standards.ieee.org/getieee802/download/802.15.4-2003.pdf ) ieee 802.11g ( standards.ieee.org/getieee802/download/802.11g-2003.pdf ) bluetooth specification v1.2 ( www.bluetooth.org/spec ) zigbee specification v1.1 ( www.zigbee.org ; document number 053474r07) zigbee security services specification v1.0 ( www.zigbee.org ; document number 03322r13) 14 revision history pll phase-locked loop por power-on-reset psd power spectral density psrr power supply rejection ratio pti packet trace interface pwm pulse width modulation rohs restriction of hazardous substances rssi receive signal strength indicator sfd start frame delimiter sif serial interface spi serial peripheral interface uart universal asynchronous receiver/transmitter vco voltage controlled oscillator vdd voltage supply table 121. abbreviations and acronyms (continued) acronym/abbreviation meaning table 122. document revision history date revision changes 11-dec-2006 1 initial release. 3-dec-2007 2 document status promoted from preliminary data to datasheet.
SN260 88/88 please read carefully: information in this document is provided solely in connection with st products. stmicroelectronics nv and its subsidiaries (?st ?) reserve the right to make changes, corrections, modifications or improvements, to this document, and the products and services described he rein at any time, without notice. all st products are sold pursuant to st?s terms and conditions of sale. purchasers are solely responsible for the choice, selection and use of the st products and services described herein, and st as sumes no liability whatsoever relating to the choice, selection or use of the st products and services described herein. no license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. i f any part of this document refers to any third party products or services it shall not be deemed a license grant by st for the use of such third party products or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoev er of such third party products or services or any intellectual property contained therein. unless otherwise set forth in st?s terms and conditions of sale st disclaims any express or implied warranty with respect to the use and/or sale of st products including without limitation implied warranties of merchantability, fitness for a parti cular purpose (and their equivalents under the laws of any jurisdiction), or infringement of any patent, copyright or other intellectual property right. unless expressly approved in writing by an authorized st representative, st products are not recommended, authorized or warranted for use in milita ry, air craft, space, life saving, or life sustaining applications, nor in products or systems where failure or malfunction may result in personal injury, death, or severe property or environmental damage. st products which are not specified as "automotive grade" may only be used in automotive applications at user?s own risk. resale of st products with provisions different from the statements and/or technical features set forth in this document shall immediately void any warranty granted by st for the st product or service described herein and shall not create or extend in any manner whatsoev er, any liability of st. st and the st logo are trademarks or registered trademarks of st in various countries. information in this document supersedes and replaces all information previously supplied. the st logo is a registered trademark of stmicroelectronics. all other names are the property of their respective owners. ? 2007 stmicroelectronics - all rights reserved stmicroelectronics group of companies australia - belgium - brazil - canada - china - czech republic - finland - france - germany - hong kong - india - israel - ital y - japan - malaysia - malta - morocco - singapore - spain - sweden - switzerland - united kingdom - united states of america www.st.com

▲Up To Search▲

Price & Availability of SN260

	To Download SN260 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .